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.
Related
All of a sudden VS2017 doesn't display the Abort, Ignore, Retry prompt when it is hitting an assert() failure. All it does is output to the output window and exit the program so I can't debug it.
I did a repair install, didn't change anything. JIT is enabled (native code), using debugging version and libraries. It's been working fine.
That is the error I am getting:
Press Retry to debug the application - JIT must be enabled)Assertion failed!
Program: C:\Test\x64\Debug\Test.exe
File: C:\Test\Test\owner-draw-buttons.cpp
Line: 144
Expression: 0
For information on how your program can cause an assertion failure, see the
Visual C++ documentation on asserts (Press Retry to debug the application - JIT
must be enabled)Debug Error! Program: C:\Test\x64\Debug\Test.exe abort() has
been called (Press Retry to debug the application) The thread 0x3524 has exited
with code 3 (0x3). The program '[10772] Test.exe' has exited with code 3 (0x3).
Any ideas on how to fix?
TIA!!
For JIT is enabled (native code), maybe you're in a C++ project. I can only guess it have something to do with Windows SDK version and the ucrtbase.dll in it.
To resolve that:
1.Please try updating your VS2017 to latest 15.9.17
2.Updating your windows OS to a newer version(1903 in my machine), see this similar issue(the download link is invalid, I suggest you update Windows system directly instead of installing the sdk separately).
After that, restart PC and create a simple C++ console project with assert(false); to check if now the dialog comes back. Hope it helps :)
In addition, as a temporary workaround, you can try _CrtSetReportMode and _CrtSetReportFile. See this.
I have a strange problem using Visual Studio 2010.
I'm running a DLL, which is loaded from IIS in the process w3p.exe from Microsoft. When I start the remote debugger on another machine and attach my local machin there, everything is fine and I can debug.
The problem is when I run it locally. I know that the DLL is loaded (because of logfiles) and I can attach the debugger to the process. But when I try to Break all I get an error saying
Unable to break execution. This process is not currently executing the type of code you selected to debug.
The project settings are definitely pointing to the project that just compiled the running DLL, so I don't really understand this error message.
Also when I set breakpoints nothing happens. The debugger is attached though, because when I stop IIS then I get an error message telling me that the debugger needs to be stopped first.
I'm using an intentional application error fopen(NULL, NULL) which will allow me to attach a debugger in the debug build. But this is rather annyoing, because I have to clear the call stack manually before I can actually start debugging. Using __debugbreak() doesn't help, so I have to use this clumsy workaround.
So can anybody tell me why this works remotely, but not locally?
So I finally found a solution to my problem.
When opening the attach dialog there is an option Attach to: Managed... with a Select button beside it. By default this was set to Managed (v4.0). Now I added Native code and this solved my problem. I can attach now locally as well.
I sure don't understand why this works on a remote machine, because the code is exactly the same though, so there shouldn't be such a difference.
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 left a program running last night, it worked fine for about 5 hours and then one of its built-in self-diagnostic tests detected a problem and brought up a dialog box telling me the issue. The program was built with debug information (/Zi). Is it possible to somehow get the debugger started so I can examine the value of some variables within the program? Or is it too late?
You can attach the debugger to the running process:
Debug > Attach to Process...
Just open up the program's solution first.
Assuming you've still got the error dialog on the screen you can break into the program and work back up the call stack examining variables etc.
For the future crashes ... if you have windbg or Visual Studio Professional, you can debug crash dumps, even when program isn't running. It is quite useful sometimes. See "MiniDumpWriteDump" on MSDN for more info.
Other than that it is "Attach to process".
Professional edition of Visual Studio have Just-in-Time debugger, that will kick in as soon as anything crashes, even if MSVC wasn't running. It will also locate source code (if debug info and source code are available) and open/create solution for you.
There is an option in the Debug menu to attach the debugger to a running process, IIRC.
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.