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.
Related
The diagnostic tools in Visual Studio 2022 Community have stopped working. It shows it's recording the CPU profile but whenever I pause the program to see the results, the tools say "There is no data collected."
It was working at one point, and as far as I'm aware, I didn't change anything and if I go into the filter drop-down menu it shows everything except "Hide native code" is selected.
How can I fix this?
In my case it happened due to service 'Visual Studio Collector Service 150" being stopped, or disabled, and therefore, not running. Once you enable the service, and re-run 'debug', diagnostic tools seem to be working, again.
This could happen for a few reasons
Your code did not execute. The program, if it started properly, didn't get as far as running your code. Put a break-point at the start of your particular code section and see if Visual Studio stops there.
You didn't include program profile information in the build. Are you building a Debug version, have you turned off debug information or profiling information.
You are building with options that prevent profiling information from being included.
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 configured my windows 7 to create mini dump files on crashes but when my application crashed, no dump file was created. The search for answer left me rather confused as to when are dump files created, when windows crashes or my application crashes?
In my case, I am looking for dump file when my application crashes. I receive a typical crash dialog that states:
TheApp Application has stopped working
Windows can check online for a solution to the problem
-> Check online for a solution and close the program
-> Close the program
-> Debug the program
So can I generate dump file for my application when it crashes? I can't produce this bug on development machine so I want to walk back from dump file. Is there any other option to trace the source of bug (to source code)?
First of all, there are different places to configure a "create a minidump on crash" setting, which are totally different.
You can configure Windows to create a kernel dump file when Windows crashes, i.e. when a Bluescreen of death (BSOD) occurs. This is done in the following screen on Windows 7:
You can configure Windows to create a user mode dump file when an application crashes, i.e. instead of the "Windows Error Reporting" dialog which would normally appear. To do so, and you know that in advance, then configure a Registry key called LocalDumps (MSDN). By default, dumps will be created below %LOCALAPPDATA%\CrashDumps and they will have the naming scheme app.exe.<PID>.dmp.
For the sake of completeness, there might be other triggers. The only sure way to tell is: when the method MiniDumpWriteDump (MSDN) is called.
I'm quite sure that you want option 2 of the above. If you have trouble with it, see whether all the conditions for LocalDump are fulfilled.
The answer given by #antlersoft does not work, for the reasons I have posted in my blog: at the time the dialog is shown, Windows has triggered a breakpoint to stop the application and it has injected a callstack of Windows Error Reporting. All in all, not a good starting point for debugging.
What would work is:
attach a debugger of your choice
press "Go" in the debugger
press the "Debug" button of the WER dialog
confirm the warning about the debugger which is already attached
click "No" when asked to start debugging using the selected debugger
Using Task Manager to create a crash dump is not recommended, since it will not consider the bitness of the application, which may cause trouble later. See ways to create good and useful crash dumps.
Minidump is created when Windows crashes. It's not intended to application crash.
If you want to debug crashes of your application, you may attach it to a debugger after it is started. Clicking on the "Debug" button when application crashes do the same. You can use the debugger of MS Visual Studio to do that, for example.
See this page for help on attaching a process to MS Visual Studio debugger:
https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx
EDIT: following text removed, as this may not work as expected (comment from Thomas)
You can also create a dump file from task manager, however you will still need a debugger to analyze it and, actually I am not sure you will be able to get the dump file at the point application crashes. The best way, if you can, is to debug the process on the target machine by attaching it to debugger either after it is started or when crash occurs.
When you get the crash dialog, go to Task Manager, find the process, right click on the process, and select "Create dump file". The dump file is created in the AppData/Local/Temp folder for the user; it will be named %AppData%\Local\Temp\.DMP; if you create multiple it will be -1.DMP, etc. You can move the dump file to your development machine and open it within Visual Studio. Visual Studio will then act as if you had hit "Break all" at the point of the crash while running the process in the debugger.
There are a number of errors going on here but I'm sure they are all linked, so first off I'm getting Access violation reading location exceptions at locations (generally near 0x00000000)
but I only get these exceptions in release and not in debug, even if i setup debugging to do so. Also I found where the error happens but when I step over that it goes in to a complete unrelated function that is not called in the line or in any of the functions in that line of code. But when similar code is called it still goes to this unrelated function but doesn't fail. This all only happens in release versions. I know which piece of code is causing the error as if I comment it out its all fine. Also in the watch window in release all the numbers are wrong most of the time, which has never been a problem but it could help also a added some code to it to output the values of variables to a file and the variables are all fine, the pointers are sensible, but when the exception happens it always says their 0x00000020 but when I look at the log they are fine. This is in 32 bit , but on 64 bit windows 7 in c++. Please any help would be good!
Visual Studio's debugger will cause the program to use a debug heap that can hide uninitialized memory if you use the option "Start with Debugging" to start your program, in release or debug. You can try to run your program built in the Debug configuration without the debugger attached, and then use the Attach to Process... option in the debug menu to attach to your executable.
If this doesn't help, I recommend using windbg to debug your program. For help getting started with windbg, take a look at the answers on this question.
Once windbg is configured and symbol paths are set up, you can use the "!analyze -v" option once the program crashes to get a lot of information about the crash automatically.
The application I'm working does not start in the debugger of Visual Studio 2005.
Here's what I do:
I rebuild the application and hit F5 to start it
The title of the VS2005-window says "projectname (Running) ..."
The debugger buttons appear but are greyed out
The application appears in the Windows task manager, but it has only 80k in memory usage
Nothing happens for a long while, and finally I get a windows with the following error message: "Debugging is being stopped but is not yet complete. You can force debugging to stop immediately, but any process being detached may be terminated instead. This window will automatically close when the debugging has completely stopped". The window does not disappear, so after a while I press the "Stop now" button.
Nothing happens for a while (the debugger buttons still visible, but greyed)
Some time later a new window appears: "Unable to start program '(path to exe)'. OLE har skickat en begäran och väntar på svar". The last sentence is swedish for "OLE has sent a request and is waiting for response". I press OK and the debugger buttons are gone.
The application is still running, and still has only 80k in memory usage.
I try to end the process with the task manager, but it is not killed.
I quit Visual Studio and finally the process is gone.
The application is an unmanaged C++ project, that use a lot of DLL-files as plugins. I'm using the "multi-threaded debug" runtime, and I've made sure all dependencies are compiled against the same runtime.
It was while doing that this problem appeared all of a sudden. I've tried to reverse my changes, but it doesn't help. Restarting the computer doesn't help either.
I've got the application running once or twice at random. If I then ended the application and started it again it wasn't started. So I don't think this is because of my configuration.
Any ideas?
One more note: the application starts and runs as it should if I start it from outside Visual Studio.
Sounds like a misbehaving DllMain() in one of the implicitly linked DLLs used by your program. You might get a hint from the Output window, it lists the names of the DLLs as they get loaded. If it is wininet.dll then you've fallen into a deadlock trap with the symbol server.
Ok, I've solved my problem, but I have no idea how.
One thing i tried was deleting all build files and exe and dll files, and then recompile everything. But that didn't help.
I then tried one thing at random: the plugins were in the same solution. So I removed them and tried to run again. And this time it worked! So I added all the plugin-projects back, and it still works!
So, I guess I will never know what happened. But removing and adding a project to a solution might solve someone elses problem too ... :)