I have a dump file generated using Windows Task Manager. The process it is created for is a Borland (now Embarcadero) C++ application.
Is it possible to use such a file for Borland applications?
If yes, then how?
As you have created a dump of an application, that's called a user mode crash dump. Such a dump is typically analyzed in Microsoft Visual Studio, Microsoft WinDbg or DebugDiag.
The debuggers are available for free. WinDbg is part of the Debugging Tools for Windows and Visual Studio 2015 is provided as a Community Edition. For WinDbg, install both versions, x64 and x86 so that you can debug any kind of dump. DebugDiag has a simple UI and doesn't allow doing manual analysis.
If you have taken the default Task Manager of a 64 bit OS to take a dump of a 32 bit application, you might be unlucky though. Try getting a 32 bit dump for a 32 bit application, that's better if you're new to debugging. This answer shows the various ways of getting good dumps. This will also be fine for you, not only for .NET.
Analyzing the dump in DebugDiag
Open the dump in DebugDiag
Select a type of analysis
Run
Read the HTML report it generated
Analyzing the dump in Visual Studio
Open the dump in Visual Studio
Press the green play button
Look at the message to see the exception
Look at the call stack
...
Visual Studio has many commands and possibilities, but explaining them all here is too broad. If you have a more specific idea of what you want to know about your dump, ask a new question.
Analyzing the dump in WinDbg
Open the crash dump in WinDbg (use correct bitness).
Set up the symbols
Start analyzing, e.g.
~ to get a list of threads, ~xs to select a thread (where x is the thread number)
k to get a call stack
.exr -1 to get info about an exception
!analyze -v to perform an automatic analysis
...
Learning WinDbg is a hard task, since most things are done via cryptic commands and not via UI, but it can do almost everything.
For specific problems, ask questions using the windbg tag.
Related
I have recently bought new laptop:Hp specter x360 i7-6500 with 8gb RAM.
I have installed Visual Studios 2015 Community in an offline mode, later I updated it.I am currently working in c# window forms.
The point is when I press the button 'Start Debugging', VS build the program in normal speed, but it takes like 10-15 sec to show the output, even for the small programs. This whole thing is for first time debugging after code editing, if I close it and run it again without changing the code, it shows the output on the spot.
And if I run the same program in my old laptop, which has lower specs and same VS, that laptop show the result much quicker.
Based on your screenshot, I see that VS tries to download PDB symbols for system assemblies, which are used by your application. Loading the debug symbols provides simplify debugging of an application but it also slows down the application loading.
You can change symbols loading settings, in the Tools-Options-Debugging-Symbols menu of Visual Studio. Here you can disable symbol loading (if you would use this option you need to load symbols manually using the Debugging-Windows-Modules interface). Or exclude system modules which usually are not necessary to debug a common application.
Check this blog post which provides a great description about how VS uses debug symbols.
Is it possible to use windbg commands like !locks and .loadby sos mscorwks from the Visual Studio command window (in a debug session)? I've noticed I can use eg k to print a stack trace, so I was wondering if there is some way to get access to the other commands.
Yes you can do this.
Attach Visual studio 2008 to your process for debugging.
Break at some code.
Go to immediate window
type !load sos
Now you are free to use any of the windbg commands like !EEHeap,!DumpHeap
There are some conditions. You need to enable unmanaged code debugging in your project properties. Normally in 64 bit version studio doesn't support this.
Have fun.
Visual Studio 2012 has the "Windows User Mode Debugger" transport in the "Attach to Process" dialog. This allows you to use windbg commands in the immediate window.
Source: Use the WinDbg Engine in Visual Studio User-Mode Debugging
Starting with Windows Driver Development Kit (WDK) 8.0 the Windows debugger is integrated into Visual Studio (see Debugging Environments). Installing the WDK on top of a Visual Studio installation will enable a developer to pick a number of debuggers from the Attach to Process dialog, or set the debugging engine in a project's Debugger settings. This has been verified for Visual Studio 2012 and 2013. The way I read the MSDN link above, this should also work for any other IDE that is supported by the WDK 8.0 and above.
While WinDbg offers a lot of powerful commands, there are some drawbacks as well. This list is not exhaustive, and merely contains those issues I did encounter:
Cannot attach to more than one process at a time. While not generally an issue, this is quite unfortunate, if you do need to debug more than one process at a time. The Visual Studio debugger can attach to any number of processes simultaneously.
WinDbg will not use the symbol settings from your Visual Studio IDE (tested on VS 2012 Update 4). While you can configure the IDE where to look for debugging symbols, WinDbg will not honor those settings. WinDbg will use the _NT_SYMBOL_PATH environment variable, and/or the configuration set through .sympath.
Different syntax for function breakpoints. This is a minor annoyance, since you cannot use Visual Studio's syntax to specify function breakpoints. This also means, that function breakpoints are ignored that have been set using the Visual Studio syntax. What's more annoying, though, you do get a warning dialog for each when launching a debuggee.
No support for Tracepoints. I've been using tracepoints extensively, to unintrusively insert tracing into a debuggee. If you are using tracepoints as well, this may prove to be more than just an annoyance.
The situation might sound a bit weird but I have to play with what I have.
There's a Win2003 64-bit server OS and a legacy application written using Visual Studio 6. The app consists of two parts: ActiveX components written in VB6 and C++ code which uses them.
I need to debug the components' code. I installed Visual Studio 6 on the server and I'm able to step into the component's code. Then I got following situation:
C++ code works until it needs to instantiate component A.
We switch to VB6 and start debugging component's A VB6 code.
In the very beginning component A creates an instance of a class C exposed by component B. At this step VB6 debugger shows error message with title "OLEDB32.DLL" and following text:
"Failed to load resource DLL C:\Program Files (x86)\Common Files\System\Ole DB\OLEDB32R.DLL"
Additional information: The last step in initialization of the class C is opening an ADO connection to SQL server using OLEDB provider.
I'd appreciate any ideas on how resolve this problem.
Thanks in advance.
The VB6 debugger has a reputation for sometimes being a bit flaky, and I'm not sure it was ever supported on 64-bit operating systems.
There are some other options for debugging VB6.
You could try debugging the VB6 in the Visual C++ 6 debugger at the same time as the C++. Compile the VB6 into native code with symbols (create PDB files). Then you should be able to step from the C++ straight into the VB6 and still debug. I have done this before (not on 64-bit). Here's a Microsoft knowledgebase article on doing this with C++ 5 - I think it's much the same in C++ 6. Here's info on doing it with Visual C++ 2008 (!)
Or you could try running the program in Windbg, a free standalone debugger from Microsoft. Again compile your VB6 into native code with symbols (PDB files) and you will be able to debug your VB6 in Windbg. You should also be able to debug the C++ at the same time.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
MDAC registers ADO/OLEDB classes like this: %CommonProgramFiles%\System\Ole DB\sqloledb.dll
Check if your process environment is corrupted in some way. If you use restart manager (when your app crashes it is restarted) does not restore environment. We guard with something like this in Sub Main
If LenB(Environ$("CommonProgramFiles")) = 0 Then
Call SetEnvironmentVariable("CommonProgramFiles", pvGetSpecialFolder(ucsOdtProgramFilesCommon))
End If
If LenB(Environ$("CommonProgramFiles(x86)")) = 0 Then
Call SetEnvironmentVariable("CommonProgramFiles(x86)", pvGetSpecialFolder(ucsOdtProgramFilesCommon))
End If
Using VB6, I have created an Outlook plugin, that has a property page. The property page is an OCX control.
When I compile the project to an OCX file, and then run OUTLOOK, things work fine: I am able to see my OCX as a tab in the Outlook options.
However, when I try to debug by running the OCX in VB6 I get an error. My debugging is started like this:
1) Debug options set to Wait for components to be created"
2) F5-RUN project in VB6.
3) Start Outlook.
4) Get the error: "Cannot display "MyOcx" page. This page will remain visible, but is not available. An OLE registration error occurred. The program is not correctly installed. Run Setup again for the program"
I suspect this is because, when debugging, the OCX is being created out-of-proc and Outlook doesn't like that.
Is there a good technique to use the VB6 debugger on the OCX in this scenario?
The VB6 debugger is sometimes flaky when debugging DLLs or OCXs.
You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 OCX into native code with no optimisation and "create symbolic debug info" (i.e. create PDB files), and you will be able to debug your OCX in-process in Outlook. Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). EDIT see Kris's answer for more details.
EDIT: Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the OCX was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives - or I'm told the serious way is to use a Symbol Server.
(Les serious) you could do without those newfangled interactive debuggers, just log to a file, or with DebugMessage calls from your VB6.
The only way you are really going to be able to Debug this is In Process as MarkJ said. Using the free Visual Studio 2008 C++ Express Edition (or even better, Visual Studio 2008 Professional if you have it, and it is available for a 90 day trial) and a PDB.
To make sure you are creating the PDB, go into Visual Basic, check the P)roject / P)roperties and click on the Compile tag. Make sure "Create Symbolic Debug Info" is checked.
Next start up Outlook, and attach to that process from Visual Studio (T)ools / Attach To Process. Make sure your Ocx is shown in the modules window, and then load the PDB (right click on the Ocx in the modules window). You will probably have to add the source code in the Solution Properties (for more details on how to do that, read this post).
It's a bit of a pain in the butt the first time, but once you can do it, it becomes pretty easy, and is far easier than trying to determine what is going on from a log.
I don't have much idea on the OCX.
However, you can use a tool which was part of visual studio named something like "activex control test tool".
As far as I know (based on my understanding of documentation), OCX is created in-proc.
If an application†crashes,
I hit "Debug" and Visual Studio is my currently registered Just-In-Time (JIT) debugger:
Visual Studio appears, but there's no way to debug anything:
I do not see any disassembly
I do not see any registers (assuming it runs on a CPU with registers)
The call stack is empty (assuming the CPU has a stack pointer)
I do not see any symbols (assuming it had any)
I do not see reconstructed source code from reflection (assuming it was managed)
Other JIT debugger products are able to show disassembly, but they are either command-line based (Debugging Tools for Windows), or do not support symbols (OllyDbg, Delphi). Additionally, my question is about debugging using Visual Studio, since I already have it installed, and it is already my registered JIT.
How do you debug a program using Visual Studio?
Alternatively: has anyone written a graphical debugger that supports the Microsoft symbol server?
†Not, necessarily, written in Visual Studio.
Edit: Changes title to process rather than application, since the latter somehow implies "my application."
Edit: Assume the original application was written in assembly language by Steve Gibson. That is, there is no source code or debug information. Visual Studio should still be able to show me an assembly dump.
Looking at the screenshot it appears that Visual Studio is currently debugging in Run mode - you need to break execution of the process before it makes sense to look at things like the call stack, etc...
To break execution of the process you either need to hit a breakpoint, or you can break execution of the process at any time by using the Pause / Break all toolbar item (Control + Alt + Break).
Then you should be able to access the following windows under the Debug -> Windows menu:
The disassembly window
The registers window
The call stack window
The modules window shows a list of loaded modules along with where their corresponding symbols are loaded from (if loaded)
Some other useful windows:
The processes window is useful if you are debugging more than one process at a time
The Threads window
The Memory window (there are four of them)
The Locals window
Some of these might not be visible by default depending on which window configuration you selected when you first started Visual Studio - if you can't find them then right click on the toolbar and goto customise to add them.
Visual studio doesn't reconstruct soucre code from disassembly - you really need to have the original source code available to you, otherwise the symbols almost certainly won't match the source code you are debugging.
If you are debugging unmanaged modules without source code then I recommend you at least try WinDbg - its user interface is a bit clunky at times, and it does have a steep learning curve, however it is a very powerful debugger supporting many features that Visual Studio doesn't - it may be more suited to the sort of debugging you need to do.
(Visual Studio is a fantastic debugger, however it's primarily used to debug modules where the source code is available and so it lacks certain features in favour of a better user experience).
Assuming this is your application that you wrote in VS, just press F5 to run the program and either use a breakpoint, or manually break the program to start debugging.
The problem in the last screenshot is that Visual Studio did not enter break mode automatically. That seems like a bug. If you hit the 'pause' button on the toolbar, it would enter break mode, giving you disassembly, and a callstack.
According to that last screenshot you were actually attached to the program ... the output windows shows it loaded stripped symbols for OLE and the crt.
You can debug a program with Visual Studio if you have the debug information available for this program. It's the difference between compiling a Release version (normally without debug information) and compiling a Debug version.
This dialog to debug a program is handy if you are testing the debug version of your self-written program. You can attach it "on-the-fly" to your Visual Studio debugger and look for the problem.
If it is not your program or it is your program, but does not provide debugging information which Visual Studio can understand, then you are out of luck.
Use menu Debug -> Windows -> Disassembly (I think the keyboard shortcut is Alt + 8, but I am configured for VC 6.0 bindings, because that's how I roll, and it may have changed).
You can get public symbols for the operating system from http://msdl.microsoft.com/download/symbols. Add it to the list in menu Tools -> Options -> Debugging -> Symbols -> Symbol file locations.
Also, make sure you are running in the same integrity level as the application. Or always run Visual Studio as Administrator.
I guess you are already in the Debug mode. The "Run" button is disabled. Just go to Debug -> windows -> Disassembly to view disassembly.