I understand that heap corruption can happen from wide variety of causes.
I have a QT C++ project in Visual Studio. If I run in Debug or Release mode from Visual Studio, everything goes smoothly.
If I run the released executable (outside of Visual Studio), I get an application has stopped working error, followed by a prompt that asks if I want to Debug. This brings up Visual Studio Just-in-Time Debugger window stating that: An unhandled win32 exception occured in my_qt_application.exe[8812]
If I choose to Debug, I get the message: Unhandled exception at (...) (ntdll.dll) (...) A heap has been corrupted.
So I keep searching in the code for causes. The problem is that this error happens at very random occasions, not very consistent.
My question is; can the cause of this be missing dlls? (I've added the dlls that allows the program to run.)
No. The cause cannot be missing dlls. It could be a proximate cause. Example: If some image plugins are not available, and your code doesn't check that QImage loading had succeeded, and then tries to operate on the null image - there may be problems.
Most likely, though, you have a plain old memory error that you should squish using e.g. Valgrind.
Related
I have a running application that crashes with "An unhandled win32 exception occurred in ..." dialog. This only contains full-fledged Visual Studio in the available debuggers list even though Visual Studio Code is installed.
I would rather use vscode as it is my main dev environment.
How can I add it to the "Choose Just-In-Time Debugger" window's "Available Debuggers" list?
Update:
I found where the setting exists in the registry, with an example of how to set WinDbg as the debugger instead of Visual Studio.
https://www.codeproject.com/articles/6084/windows-debuggers-part-1-a-windbg-tutorial#_Toc64133667
and
https://learn.microsoft.com/en-us/windows/win32/debug/configuring-automatic-debugging
Remaining step is to determine how VS Code's debugger likes to be invoked.
(I'm still open to cleaner ways to do this, however.)
Update 2:
Nearest I can tell, this last step is the big deal breaker.
According to this feature request:
https://github.com/Microsoft/vscode/issues/10979
It doesn't look like the team at Microsoft is interested in making that an option. :_(
I am currently working on fixing a project for a client. A little information about the project first:
Originally developed in Visual Studio 2012 using xp_v110 build tools
Multiple projects in the solution
Currently updating/debugging in Visual Studio 2017 using VS 2015/xp_v140 build tools
Working on Windows 10
The application will run in debug mode, however if I just leave the application after starting the debug session (i.e. not opening/clicking on the application to open it as it starts minimized in the tray), the application crashes after 1-2 minutes.
Unfortunately the IDE is showing that the crash is taking place in chkstk.asm with the following message:
Exception thrown at 0x0064EDF9 in <<exe name>>: 0xC00000FD: Stack overflow (parameters 0x00000000, 0x000A2000).
I have updated the exception settings to break when all C++ Exceptions are thrown, checked the box that says "Break when this exception type is thrown", and wrapped the initial method that runs in a try block, however I can never catch the error in the C++ code; it always occurs in the chkstk.asm file.
Any suggestions on how I can find out where in the C++ code the exception is occurring. Like I said, this is an update for a client and the original programmer is not available, and they never commented their code, so it is difficult enough trying to go through all this. Any help/suggestions would be greatly appreciated. Thanks in advance.
I am getting Exceptions in the Output window of Visual Studio but do not know what code is causing these exceptions. I would like to get a stack trace so I can properly debug them.
Here is a sample of the exceptions I am getting:
The one I am particularly interested in in the NullReferenceException.
I have looked at this SO post:
How do I find the stack trace in Visual Studio?
But my menu looks like this:
I tried to follow these instructions for adding the "Exceptions" choice to the Debug menu but all I can find it "Exceptions Settings":
Seeing a stack trace of an exceptions seems like such a common need I have a hard time believing that VS is hiding it.
I noticed a tabbed panel on the bottom of VS and was able to modify the Exceptions that cause VS to break on the "Exception Settings" tab.
When debugging a native win32 application, certain unhandled exceptions (more specifically a failed assertion in Windows atlcomcli.h) causes the "unhandled exception" dialog (where you can abort, continue (to debug the exception in visual studio) or ignore) to freeze and be unresponsive - none of the buttons can be pressed.
This means I cannot get the callstack among other things, I have to force-terminate Visual Studio and so I cant get any help on debugging where it crashes.
It works just fine with most other unhandled exceptions that are thrown.
Why is this?
One workaround is that you could collect the minidump file for the crashed/freeze issue, debug the crashed dump file and find more helpful information for it:
How can I disable the debug assertion dialog on Windows?
I have a rather large project I'm working on in C++/Win32, and now that I'm nearing completion, I wanted to start testing it on other machines. My project works great in Visual Studio - either in Debug or Release mode. However, if I try to run either executable from its build directory (with all of the supporting files in place) they crash. I tried using the debug feature provided by visual studio, and it opened malloc.c, saying that a heap has been corrupted. If I had a memory leak or something somewhere, why wouldn't I be getting this error when I run my project from Visual Studio? I could use some pointers on how to debug what the problem might be.
I don't think that is due to memory leak. It has happened to me too when I tried to copy only the compiled executable but not depend libraries. So just check whether all depend libraries are available in other systems too.