Can any one tell me how to use the WinDbg .
I am created an Application it is works fine in one machine.when i try to run on another machine it fails how can i debug it using windbg.
Start by downloading WinDbg from:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
You can install it on the target machine, and it will be listed on the Start menu under "Debugging Tools for Windows".
The general idea is to start your application, start WinDbg, attach to your app process, and run under the debugger. Try to provoke the failure and inspect the state of the process with the debugger.
The most common commands are available from the menus, and the help file is excellent for discovering the rest.
Here's a tutorial to get you started:
http://www.codeproject.com/KB/debug/windbg_part1.aspx
After you install windbg from http://www.microsoft.com/whdc/ you can start debugging your app. Windbg ships with help on commands, so feel free to use it by pressing F1 in the debugger any time.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
Having one heck of a time debugging a crash in a Windows Service that I've build with QT and Boost Logger on Windows using MSYS2 environment. The main issue really comes when I stop the program right before exit. The program just doesn't exist successfully and throws one of these bad boys:
If I was running it in gdb it might be a different story. I open the crash dump in windbg and get some info, but since the symbols aren't exported it's really cryptic.
I see some issues when my program (called service) is calling the log. But I can't do much here in the way of where or what. How can I get something useful so I could finally solve this issue?
Thanks so much!
Seems like the easiest and most natural way was to attach gdb to the running process. I simply ran msys2 as Administrator, then ran the command
gdb service.exe -p [processID]
Task manager gave me the process ID. As soon as the process was attached I just used the command
continue
to get it to continue running. Then I let it crash and gdb gave me the backtrace perfectly.
I've searched a bit for this and this was much simpler than trying to get windbg to read the symbols generated by g++ or read the assembly code. Hope this helps somebody having the same issue.
References:
How to attach a process in gdb
my Qt (QML/C++) application crashes and I can not find the reason why. I tried to output a lot of information but some signal/slot connection probably causes a crash. I spent many hours trying to find the reason but I failed.
The only good point is that I can reproduce the crash whenever I want.
Unfortunately I don't know hot to use the included GDB debugger. This is the output I got:
How do I find from this what happened and where? I need to find at least the function, in which my application crashed.
Or what else could I try? Unfortunately I can not disable the signal/slot connections or the associated functions, because then I can not get to the point, where it crashes.
Qt has detailed documentation on how to install a debugger found here: QtCreator Debugger
MingW does have a GDB that can be used to debug the application better. You can also use CDB to debug, just depends on your preference.
Once that is installed, you'll be able to set breakpoints and check variable information to see where your program is crashing using the Debugger view in QtCreator.
Tools->Options->Build & Run
If you have Qt version kit like this you need to check debuggers.
https://i.stack.imgur.com/LaY1p.png
https://i.stack.imgur.com/8kTG6.png
You need to install MinGW and after install you will be have debugger. After install press F5 to start debuging.
I have an C++ application, that crashes on a computer of some person on the other end of the world. There's no way for me to simulate it or get the same computer. The person is no developer, so I cannot really ask him to install Visual Studio or something. I have pretty deep debug logs, but they didn't reveal anything usable.
Is there a tool, that could generate the stack trace of the application at the moment of the crash? Such thing is available inside OSX, but seems that Windows doesn't have it.
You can use procdump. It can be setup as a debugger to automatically create dumps for crashing processes.
Procdump is part of Sysinternal tools and can be found at:
http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
Relevant switches:
Create a dump for a hung application:
Write a mini dump for a process named 'hang.exe' when one of it's
Windows is unresponsive for more than 5 seconds:
C:\>procdump -h hang.exe hungwindow.dmp
Automatically create dumps for crashing apps:
Register as the Just-in-Time (AeDebug) debugger. Makes full dumps in
c:\dumps.
C:\>procdump -ma -i c:\dumps
Create a dump for a pid:
C:\>procdump <PID>
You can read the dump files using windbg: Getting started with dump file analysis
Use google's lib that makes minidump for msvc to debug.
CrashRpt
Since google seems to lead here for all "stack traces of windows" you can also get the stack trace of a running process using "sleepy" or "very sleepy" utilities.
another option: run it in gdb.exe, hit ctrl+c
I'm trying to debug shell extension (IContextMenu) in Windows 7 with Visual C++ 2008. I have set DesktopProcess=1 in the registry and set host app to explorer.exe. But when I start the debugger, it launches explorer.exe and then detaches from the process. DllMain of the shell extension isn't called.
The same code with exactly the same settings launched in debugger without any problems in Windows XP + Visual C++ 2008.
Any thoughts how to debug the shell extension in Win7?
I've found a nice workflow that I think is the fastest way to rapidly iterate the code-build-test cycle when developing shell extensions. The following should work on any Windows version.
First prepare - set the start program of your shell extension project to be c:\windows\explorer.exe and also set it to be the start-up project.
Then, whenever you want to debug your shell extension perform the following steps:
Click on the task bar and press Alt-F4 - this will bring up the shut down dialog
Press Ctrl-Alt-Shift-Escape - this combination will close explorer.
Use Alt-Tab to go back to Visual Studio and press F5 - explorer will now launch with the VS debugger attached to it from the very beginning.
When done, just stop the debugger session. This will kill the debugged instance of explorer and will also automatically start a normal instance of it. This will also unlock the shell extension DLL so that you can build it again.
Caveat on Vista and 7 - be sure to run the Visual Studio that you use for debugging in non-Administrator mode (non-elevated), so that the explorer is started in its usual non-elevated mode.
Try launching explorer and THEN attaching the debugger to it.
You could try putting a DebugBreak() call in your code. This should launch the just-in-time debugger at the call and give you an idea of what is going on.
You should take a look at gflags.exe, part of the standard debugging tools sdk. It's got all the options you need to configure (global)flags for any process startup/services/heap/pool-tagging/stacktrace's-on-allocation etc...
Debugging Explorer.exe is usually overkill for extensions that operate in a shell view.
I personally use a little app I made that hosts an instance of IExplorerBrowser similar to this example. If your IContextMenu item is not the default item then you can just use Notepad.exe and its open file dialog...