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.
Related
I have a java application that communicates with JNI C++ application. My java application is in eclipse while I am using netbeans for C++ with mingw64 bit compiler. I can not seem to debug JNI part of the application.
I load dll in java application. From netbeans I go to Debug->Attach Debugger select javaw.exe that makes my eclipse stuck and I get exception in eclipse IDE:
org.eclipse.jdi.TimeoutException. Timeout occurred while waiting for packet. occurred creating step request
Is my debugging procedure correct? How does one configure netbeans to debug a JNI application.
This could be because your debugger is stopping all your threads when attaching, and not letting them resume properly afterwards (Not sure why this happens. It seems to only happen on some computers, and work fine on others).
A way to around this that worked for me is - In your C++ debugger configurations, in the debugger tab, tick the "Non-stop mode" checkbox. This will stop your debugger from stopping your threads, and the timeout should stop happening.
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 am running a Qt C++ Project in Visual Studio 2008 and I got this error message:
"The program can't start because QtCored.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtCored4.dll from C:\Qt\4.8.0\bin to the exe program
I run it again, I got:
"The program can't start because QtGuid4.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtGuid4.dll from C:\Qt\4.8.0\bin to the exe program
Then I run it again, I got:
"the application was unable to start correctly (0xc015002). Click OK to close the program.
Then I check the Event Viewer, I see this:
Activation context generation failed for "D:\rest\rrpT.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
could not be found. Please use sxstrace.exe for detailed diagnosis.
First of all, it is very strange to me because I am building and debugging the application on VS2008 but it asks for the dll files form VS2005. Then I copied those files from VS2005:
msvcm80d.dll - msvcp80d.dll - msvcr80d.dll
to the program folder but it is still the same error :(
And I think there is also something interesting:
Activation context generation failed for "C:\Bin\QtSolutions_PropertyBrowser-2.5d.dll". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.
why is that PropertyBrowser is dependent on VS2005?
Any idea?
It sounds like your copy of Qt was compiled with VS2005, thus it probably has a dependency on the version 8 runtime DLLs. But your application is built with VS2008 and thus has a dependency on the version 9 runtime DLLs. In general, you can't get both versions of the runtime DLLs into one process. VC++ tends to break binary compatibility between major versions.
You need to recompile your own copies of the Qt DLLs with VS2008 or develop your application with VS2005.
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.
i have strange problem , my application (exe) is working fine in debug mode in windows 7
but stop to work with exception when compiling in release mode .
how can i debug the program to find what is causing the exception this is application with more then 300,000 lines of code ..
Compile in Release mode but create the .pdb files: How to generate PDB’s for .net managed projects in release mode?
Deploy the .pdb files to same folder as the .exe.
Then attach to process.
Check the projects settings which are different for debug and release modes, maybe you will find an answer there.
Compile release mode with debug information and turn off optimization. You will have debug version compiled with release defines. If it fails the debugger will show you bad place.
Just turn off optimization. Once upon a time that was an issue for me. In this case it will be really hard to find out the cause.
Create PDBs, it can be done for native C++ too.