Squashing Bugs
by Jim Kogler
MAK ONE products are amazingly beautiful and complicated things. VR-Forces is built from millions of lines of code and is designed to simulate the planet. As a result, the number of things our customers can do is extensive – the sky is the limit (well, outer space is the limit)! MAK runs our products through Quality Assurance (QA), of course, but the sheer number of ways people can build a scenario and interact with a product like VR-Forces prevents us from testing absolutely everything. MAK uses a combination of automated and manual testing to try to find hidden bugs before you do. But sometimes we fail, and a crash bug makes it through testing and is found by customers.
What happens then?
When customers discover a crash, it can sometimes be difficult for us to determine how to fix it. Frequently, we will need to know exactly what the customer was doing to make the crash happen. Often, customers are in secure areas with complicated scenarios and are unable to give us sufficient replication procedures. If we cannot repeat it, we often cannot fix it.
Over the years, MAK has made a few changes to our software to try to improve our ability to fix the problems that customers run into. About three years ago, we introduced ‘.dmp’ files when the application crashes. A “Dump” file (or .dmp) is a binary file that the application can develop that allows someone with a development environment to load the file and get a stack trace. The stack trace is just a map into the code explaining what line the program crashed on. To read the .dmp file, you need to have some additional files called “PDBs” and a development environment. Once the .dmp file is read with the PDBs, MAK can often (not always) find and fix the problem.
Here's a short video where Jim describes how to install PDBs.
This approach helps a lot, but it requires customers to get MAK .dmp files, or for customers to have functional development environments set up where they can collect the call stack. This is often difficult for customers as many MAK ONE deployments happen in classified environments. The fact that the .dmp file is a binary data file makes it almost impossible to remove from a lab and send to MAK.
VR-Forces 5.0.3 (and all forthcoming versions of VR-Forces) have introduced a new feature to make this process much easier. If customers install the PDB files into the VR-Forces installation, a crash in VR-Forces will generate a text readable call stack file. This will be a text file that is easy to verify and remove from a closed lab. Further, the file can be easily emailed to MAK Support, and it is likely that MAK will be able to identify and fix the crash. Again, we are not *always* able to fix a problem from just a call log, but having it goes a LONG way to understanding what the problem is.
When your application crashes, you should now see something that looks like this:
If you are able to send
To make this work, you will need to install PDB files with your VR-Forces install. The PDBs for all releases are available via support, and for 5.0.3 you can download them from the MAK ONE Download pages.
If you have any questions or concerns, please feel free to contact
