WinXP used. When I click the default cross icon to close my application. The win form of my application disappeared, but MyApp process still alive in the processes list when I open the task manager window. About 5 seconds later, throw out the unhandled win32 exception error.
Where can I set the break point? I don't know how to debug it. Thanks.
[updated]
What is the exception received?
When I run MyApp.exe(Debug Version).
Visual Studio Just-In-Time Debugger Window
An unhandled win32 exception occurred in MyApp.exe[520]
The [520] always changed to different numbers. such as [5904],[304],etc.
You just run it under your IDE, it will show the location of the exception. If you do not have an IDE; note the address of the exception from the information dialog, look that address up from the MAP file generated with the EXE and try to locate the function...
Attach your Vc to the program.
Enable catch of all exeptions.
Close your application and see where it stops.
Related
I cannot get dump files created with Task Manager (32 or 64 bit) or Process Explorer to give useful results in WinDBG or Visual Studio 2015, whereas the dump written directly from VS works brilliantly in both. I need Task Manager dumps to work so that I can analyse dump files sent by my end users.
I have reduced the problem to the simplest possible Win32 application, created in VS 2015 C++, with a deliberate NULL pointer write to cause an exception. If I run the program in VS and use Save Dump As when the exception occurs, then the dump file can be used in VS and WinDBG to see the code causing the problem. This is as expected.
However, if I run the application outside of VS, then Windows shows the usual dialog:
“Win32Project.exe has stopped working … Debug / Close Program”.
Whilst this dialog is still active I go to Task Manager 32bit and select Create Dump file. But loading this dump file into VS or WinDBG gives no useful information. In particular VS shows Exception Code as “not found”. Clicking on “Debug with Native only” causes “The application is in break mode to be shown”. See below…
I am running a new Win 10 64bit PC. DMP, PDB and EXE files are in the same directory, and I have tried endlessly with symbol directories
Visual Studio 2015 output after loading .DMP file:
Dump Summary
------------
Dump File: Win32Project1 (4).DMP : C:\Users\Rob\AppData\Local\Temp\Win32Project1 (4).DMP
Last Write Time: 24/08/2017 16:38:27
Process Name: Win32Project1.exe : C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe
Process Architecture: x86
Exception Code: not found
Exception Information:
Heap Information: Present
System Information
------------------
OS Version: 10.0.15063
CLR Version(s):
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Win32Project1.exe C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe 0.0.0.0
ntdll.dll C:\Windows\System32\ntdll.dll 10.0.15063.447
kernel32.dll C:\Windows\System32\kernel32.dll 10.0.15063.296
...
Why does that happen what you see?
It works in Visual Studio because the debugger is already attached. The debugger is informed about the exception before the process terminates. The debugger will halt the process before the Windows Error Reporting Dialog occurs and create a crash dump when the original exception is still active.
To learn more about the process on how exceptions are passed from the program to the debugger (first chance), back to the program (catch block), to the debugger again (second chance) and finally to the OS, google for the term "exception dispatching".
It does not work with Task Manager, because exception dispatching is already in its last state, which is "get handled by the OS". This makes Windows halt the program by making use of a breakpoint. It then shows that dialog. When you create a crash dump now, it's too late and it's very hard to get useful information from that crash dump.
What options do you have?
a) Windows Error Reporting
The mechanism that applies here is called Windows Error Reporting. If you had an account at Microsoft, your customer could simply click the "submit" button. You would then get some information from Microsoft. The way you ask the question makes me assume that you don't have such an account.
Then, use a feature called LocalDumps (MSDN). It's a Registry key to configure Windows to save a crash dump on disk. Make sure you understand what you need from such a dump in order to configure it correctly. In doubt, have a look at How do I take a good crash dump for .NET and use the same settings (full memory user mode mini dump). It will be good for C++ as well.
It might even be possible to activate this Registry key while the dialog is shown but I have not confirmed this any more since 2014 and I can't recommend it.
Check if your settings work by using your null pointer dereference sample application. To do so, rename your executable to the same name as your actual program.
b) Attaching a debugger
Attach a debugger to the process, then let the application continue. Press "Debug" on the dialog and confirm the message that says "a debugger is already attached". The second chance exception is thrown again, the debugger will get it and you can take a crash dump.
If you need screenshots, see my article about it
Note that in approach b) you can make many mistake which will lead to improper results. The safe way is to activate LocalDumps as described in a)
I recommend giving ProcDump from Windows Sysinternals a shot. You can set it to capture a dump of your app when it crashes, or set it as the Just-in-Time debugger and have it write a dump for any app crash.
See the documentation and examples in the above website for more detail.
I have a c++ application, that is corruption the heap. When I execute it, I get a popup from the "Microsoft Visual C++ Runtime Libraray" with the title "Debug Error!" and the error message "HEAP CORRUPTION DETECTED: ...".
I have a jenkins running several jobs. When this error occurs, this popup shows up and the execution blocks, blocking my slave.
My question: How can I change the behavior of windows and/or the run time library, so the offending application just gets aborted and this fact gets recorded on stdout? I have seen some answers using drwtsn.exe, but this tool does not exists for newer windows. Also disable the Windows Error Reporting did not work as expected.
Thanks for your help!
If you can modify the offending application, call SetUnhandledExceptionFilter to call e.g. abort so the dialogs are not displayed. For details see http://msdn.microsoft.com/en-us/library/ms680634(VS.85).aspx
I have my (native C++) DLL project and a corresponding test EXE project based on Google Test. While debugging my DLL via this EXE I have exceptions automatically handled by Google Test. So if my DLL throws an unhandled exception during debug, I expect to see error message from Visual Studio with debug session paused after the code caused exception. Instead, I have breakpoint triggered in gtest.cc. And if I disable --gtest_break_on_failure flag I will receive no breaks at all.
I found no such option in Google Test documentation. Have I missed it? I don't want to check "break when thrown" flag for different exceptions in Debug settings, because I'm only interested in unhandled ones.
The answer is in the Advanced page section called "Disabling Catching Test-Thrown Exceptions". What you have to do is invoke your binary with --gtest_catch_exceptions=0.
On Windows 7 64-bit, I use Qt 4.5.3 to call QFileDialog::getSaveFileName. Immediately on calling this function, my process crashes with the message "The RPC server is unavailable".
I found this, but it doesn't solve my problem:
"The RPC server is unavailable"
Any ideas?
I'm having exactly the same problem, but with Qt 4.7.0. Windows 7, 64-bit.
Calling QFileDialog::getOpenFileName or QFileDialog::getSaveFileName crash my process with the following message: "First-chance exception at 0x7486b9bc in SoundManager.exe: 0x000006BA: The RPC server is unavailable."
The RPC Server is running in my services list.
The only way that i found (not clean) to bypass this bug is to add the Win32 exception 0x6BA in the exception list of Visual Studio (CTRL+ALT+E) and disable it. The Exception is not thrown and my program still work after a call of these functions. I have to do this manipulation on each computer that we are using for software development.
All Windows 7 64 bit here are having the same behavior.
The combination of these 2 posts helped me understand the problem and solution:
How to: Break When an Exception is Thrown (MSDN)
How to make visual studio break only on unhandled exceptions? (stackoverflow)
Unchecking Debug->Exceptions->Win32_Exceptions helped me.
I work on a legacy MMC application and one thing I have noticed is that once in awhile when closing the MMC, an error will be reported.
"MMC has detected an error in a snap-in. It is recommended that you shut down and restart MMC".
How can I debug this? The error is not displayd until you close the console and if you try to attach a debugger, it just exits instantly.
Any thoughts?
Why not run the MMC under debugger? Clearly there is something wrong (Unhandled exception probably) with the shutdown code of the snapin.
Just run mmc.exe under your favorite debugger and tell the debugger to stop on all exception. attach your snapin exit and wait for the crash.
You can try to run ProcDump which can create dump files on Unhandled exception.