I have created a minidump using win32 api
[DllImport("DbgHelp.dll", SetLastError = true)]
private static extern bool MiniDumpWriteDump(
dmp file is successfully created.
i am trying to open this *.dmp file in another visual studio instance to locate the place of the crash,
in visual studio --> FILE--> open project the dmp file option is not available.
i had choose all files in file open menu, and opened the dmp file. but i can't debug,
any idea why my dump file option in visual studio is disabled.
i know i can use windbg, and other tools, it will be easy for me to use visual studio as it is available for me.
I'm not 100% sure. But, I think even if you get it open in VisualStudio, VS doesn't support half the commands that WinDbg does for analysing a dmp. So, I'd just stick to WinDbg. WinDbg is a free download... so that's available to you too. It's not the easiest to use, I always have to open the help to find the commands I want, but it does do a good job.
Download here for 32bit:
http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
It sounds like you are opening the dump correctly.
Here is what is says in the Visual Studio Help files:
"To open a dump file
On the File menu, click Open, and then click Project.
In the Open Project dialog box, locate and select the dump file.
It will usually have a .dmp extension.
Click OK.
To find the binaries for debugging a crash dump, Visual Studio 2005 looks in the symbol search paths. To make sure Visual Studio 2005 finds the binaries, you can add a symbol search path in the Options dialog box or from the Modules window. For more information, see How to: Specify a Symbol Path."
You yourself say,
"...and opened the dmp file. but i can't debug"
So you are opening the dump file OK in Visual Studio, but what do you mean, "I can't debug?"
If you can't see your source code, that's because Visual Studio doesn't know where it is. Follow the instructions to set up the symbol search path.
If you can't step thru your code, that's because you can't do that with a minidump. The process that produced the minidump is gone, and it can't be executed further.
If you can't examine the call stack or contents of variables, that's because Visual Studio can't find the .pdb file with the debug info.
Related
We have a legacy Visual Studio 2003.NET C++ DLL project. Still works with VS2003 on Windows 10 but we're looking to migrate to VS2019.
In VS2003 when you debug (F5), the box Executable for Debugging Session pops up. In the Executable file name box you select Browse... and navigate to the .EXE which will consume your DLL. Great!
But how to do the same in VS2019? Whenever I debug, Visual Studio thinks I'm using the Local Windows Debugger and I get the error "[PATH][PROJECT].dll is not a valid Win32 application". The Debug > Attach to Process... option is not right either because my target executable is not running yet.
If I'm understanding the problem correctly, I think you want to select the Debugging section of your DLL project's property pages. There you can choose which debugger to use and you can even set the executable you want to launch.
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
I have a program (32-bit .exe written in C++) that runs fine in the Debug directory of my project development tree but when I move it to another folder on my PC it crashes. I want to run it in the debugger from the new location to debug it. How do I start my .exe in the debugger at some arbitrary location on my PC?
I'm running Visual Studio 2013.
I want to set a breakpoint at the first executable line and step from there, just like I would if it was in the normal Debug path.
You could always add this somewhere in your app, which will open a prompt to attach a debugger when the app is run.
#if DEBUG
if (!System.Diagnostics.Debugger.IsAttached)
Debugger.Launch();
Debugger.Break();
#endif
In Visual Studio 2013, go to project properties, select the Debug configuration and go to Debugging. Enter the command, command line arguments and working directory.
Here's a screenshot of how it looks like:
Be sure to not move the PDBs. The EXE contains a reference to the PDBs and if the PDBs are not in the original place, Visual Studio cannot find them.
If you have already moved the PDBs, set up the symbol path accordingly in Tools | Options | Debugging.
The dialog looks like this:
I write a C++ program. It can be run by visual studio in Debug mode, but when i click the .exe file in the path: C:\Users\user\Documents\Visual Studio 2010\Projects\NewProj\Debug, it will show "Fail to open the file". I don't know why. My program read some text from a .txt file, after doing some processes, some texts will be output to another file.
Thanks:)
Try switching from debug mode to release mode. Then from the menu in Visual Studio: Clean solution and rebuild the solution. If you get the same error try looking through the event viewer to see a more detailed exception.
I used to work with VS 2008 but I am missing the following feature in VS 2010 when debugging MFC C++ app:
whenever an assertion occurs, VS 2008 automatically opens the source file and focus the line with an assertion expression
in VS 2010 I have to mark the file name and line of assertion and then manually open the source file and scroll to the expression
Is there some option or registry setting how to enable such behaviour in VS2010 like it works in VS 2008 ?
The first setting that really matters in in the Project + Properties, General page, "Use of MFC". You'll have no trouble if you select the "Use MFC in a static library" setting. This causes the linker to generate the debugger .pdb file entries for MFC symbols, giving the debugger an easy time to find the MFC source code files on your machine.
This isn't always practical however, the "Use MFC in a shared library" setting is the normal one. Which will load the MFC dll from c:\windows\system32, put there when you installed VS. Getting a .pdb for this DLL requires enabling the Microsoft symbol server, Tools + Options, Debugging, Symbols. Press F1 to get config help for this setting page.
You can verify this worked out by using Debug + Windows + Modules while debugging and checking the Symbol File column for mfc100xx.dll. Right-clicking the module and Symbol Load Information provides additional info, showing which directories were searched to find the .pdb
A further complication is that the .pdb that the debugger will download was created on a build server in Redmond which had the source code files installed in f:\dd\vctools\vc7libs\ship\atlmfc. Obviously not the directory where you have them installed. The IDE will prompt you for the actual source code directory. This prompt is often highly confuzzling so clicking Cancel on the dialog is a common thing to do. You now however bought the farm, the IDE remembers that you cancelled this dialog and won't prompt you again. You reset that by deleting the hidden .suo file in the solution directory.