These steps are modified from instructions sent out by Paul Harrington, a dev lead on the VS Tools Platform team:
Unfortunately there are scenarios where a VS crash will NOT result in a Watson dump. Some situations where this can occur:
- Bug causes a stack overflow and memory cannot be allocated for Watson
- Some CRT security checks (buffer overrun detection, for example) bypass the Unhandled Exception Filter (UEF) intentionally.
- If someone tries to add a vectored exception handler that isn't marked "safeSEH", the the OS will terminate the process.
In such cases, here’s how you can obtain dump information and help us resolve the issue:
- Launch VS
- Get to the point where the issue is about to repro
- Launch a second instance of VS
- In this second instance, go to Tools | Options | Debugging | Symbols
- Add a new symbol search path http://msdl.microsoft.com/download/symbols, and specify a local cache (e.g. C:\Symbols).
- Then (still in this second instance of VS), go to Tools | Attach to Process
- In the Attach To section, make sure at least Native is selected
- In the Available Process list, locate the first instance of VS and attach to it (you may have to accept the public symbol server EULA at this point)
- Once attached and the symbols are loaded (watch status bar at bottom or open the Modules window to verify when symbols have finished loading) go to Debug | Exceptions and ensure that Win32 Access Violations is checked to be thrown when encountered (crashes on VS shutdown are often the result of an AV)
- Now go back to the original instance of VS and finish the steps required to reproduce the crash
- The second instance of VS should break
- In the second instance, go to Debug | Save Dump As and save the dump file
- Attach the dump file to the appropriate bug in the MSDN Feedback Center, or if you are dealing with someone at Microsoft already, send it to them directly.
Thanks for continuing to help make Visual Studio better!