I have an .exe that crashes in release mode. I want to debug where the crash occurs.
How can I use VC++ to debug a crash in a release-mode .exe?
You can run Visual Studio and attach it to a process to debug.
Also check through the Windows Event Viewer (an often overlooked source of information) for any exceptions that Windows may have caught.
Firstly if you have access to the code you can open the workspace in visual studion and debug it by pressing F5 button.
Secondly go through the steps that leads to the crash. At that point of time check the location pointed to by the call stack.
This will give you indication on the funciton or line where crash is occuring.
We are assuming this application was written in VC++. How often are you able to reproduce this issue. Is it like everytime you can reproduce it or how is it.
Related
I have a C++ application (it's built using Qt 5.8 library and works with PostgreSQL 9.5 database in case it's relevant). The application is build by MSVC 2012 compiler, is 64-bit application and both debug and release versions run normally on their own and under cdb debugger.
When I try to profile the running application by Visual Studio instrument (Analyze -> Profiler -> Attach), it seemingly hangs as soon as it tries to do something meaningful: simply resizing a window or clicking on checkboxes works, but any attempt to compute new values and write them to database never succeeds, as if control flow didn't return from some call.
When I stop the profiling, Studio marks as a "hot path" sequence of calls RtlWalkFrameChain->RtlpWalkFrameChain->RtlpLookupFunctionEntryForStackWalks->RtlLookupFunctionTable->RtlAcquireSRWLockShared.
RtlpWalkFrameChain has the biggest "exclusive samples" count.
Trying to filter data to exclude initial several seconds of run (until the apparent freeze) results in "No Call Tree Data Is Available" message.
I didn't manage to find any article or post with a similar problem.
The project is build in Qt Creator (I don't have a project file Studio would understand, so I can't run "normal" performance analysis).
OS is Windows 7, exact version of Visual Studio is 11.0.61219.00 Update 5.
Any idea on the subject would be welcome.
Upd: When I try to profile the application with Luke Stackwalker profiler, it aborts with the message ERROR: StackWalk64-Endless-Callstack!. The only relevant comment about the message I found is this Stackoverflow question. When I run application under cdb debugger and then try to profile it with Luke Stackwalker, the error message is the same, but subsequent pause in the debugger shows the proper (or at least believable) stack for all threads. For the working thread debugger points to a line of code inside system library and doesn't advance no matter what I do (once again, without profiling attempts the application runs normally, debugger or not).
I recently converted a mingw/cygwin build to a Visual C++ cl.exe build and upon initial testing found it crashes at launch. I then installed it in my developer environment to debug it, under which it runs just fine. My initial suspicion was that I was linking to a different DLL in that context, but examining both processes in both contexts with Process Explorer showed that they were using the same versions of the same DLLs.
Since I can't reproduce the issue with Visual C++ installed I installed the remote debugger on the client machine, but I can't manage to attach to the process quickly enough before it crashes. Is there a good way to go about doing this? This would be easy if I could launch the process under the debugger locally, but that doesn't look like a viable option here.
Any help would be greatly appreciated. Thanks for your time!
You should be letting the remote debugger start the debugee process on the remote machine.
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.
I have a couple of MVC projects which use SQL CE 4.0 and Entity Framework. Since moving to Visual Studio 2012 I keep getting the following error (not every time, but frequently)
LoaderLock was detected
Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.
The error does not occur if I go back to using VS 2010, which makes me fairly certain it is an issue with Visual Studio rather than my code, but I would like someone to confirm that for me!
Edit
The problem always seems to occur when the Dispose() method of the dbcontext is called. Here is a screenshot of the Exception Assistant:
I switch this off. As it is warning that the application could hang, if your program doesn't hang, then you're probably fine.
The problem can be solved in the same way though, by switching off the
MDA:
Debug -> Exceptions -> Managed Debug Assistants
and unchecking the LoaderLock item.
I also had a problem with LoaderLock when I was working with some external dll in my C# application.
for the .NET 3.5 I just uncheck Thrown option in Exceptions menu (Loader lock error)
for the .NET 4.0 I added <startup useLegacyV2RuntimeActivationPolicy="true"> in app.config
I've written what should be a very simple unit test using the Native Unit Test project in Visual Studio 2011 Beta. The test builds and fails (not unexpectedly), and I need to debug it. When I try to launch the test under the debugger, the debugger never starts, and instead presents this dialog which lingers indefinitely:
Anyone know what might cause this? I've never had this problem with previous versions of Visual Studio.
Update:
I've opened an MSDN thread on this: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/db3213f8-9658-4470-9e3f-3b67ec954fae
I also opened a connect bug (which apparently was just summarily dismissed): https://connect.microsoft.com/VisualStudio/feedback/details/735369/debugger-wont-start-for-native-unit-test#details
I would need to know some more information regarding this issue but it seems like it is possible that the DebugAttachProcess() method in windows isn't returning which can happen in the case that you do not have enough permissions to do so... make sure you run VS as Administrator, also, you can try to debug it in ollydbg to see if it is an executable problem, although it wont give you the source (you're stuck in assembly).