How can I abort a long operation in WinDbg? - windows

Often WinDbg will enter a state where it is *Busy* performing an operation.
Often this is due to some mistake I made trying to dt some_variable_itll_never_find or setting a break point somewhere without symbols or the 1000's of other mistakes I make fumbling around this tool.
Is there a way to cancel the current operation?

I don't have the tool now, but as far as I remember it should be Ctrl+Break.

Sometimes Ctrl+Break doesnt work. At that point you may use Debug menu -> Break.
Thanks

Ctrl+Break
will forcibly Debug break all but if for instance you entered some windbg command that takes a long time and you want to kill that then you should enter
Ctrl+c
This will kill the current running command.

You probably had "http://msdl.microsoft.com/download/symbols" in the symbol path.
Windbg will try to locate all your PDBs on Microsoft site :-(.
Pressing Ctrl+Break is not fast enough.
What I usually do is to unplug the network cable, until Windbg wakes up.
Just be carfull, if Windbg was realy downloading one if its OS DLL, the DLL gets curropted. You will need .reload /o to fix that DLL. I only unplug when I know all OS DLL were already downloaded.
To avoid this delay in the first place, uncheck "Resolve Unqualified Symbols" found under the "Debug" menu.

Related

x64dbg cannot open an exe file (but can attach it), why?

If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins

Linking Windows Debugger to Project

i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.

How to break into KD(Windbg) for Explorer crash

I see a crash in Explorer.exe, due to our security s/w dll loaded in to the Explorer.exe.
The crash happens during the shutdown of the system. The VM is connected to the Kernel debugger. I don't see Kernel debugger breaks when exception happens. I tried all debug event filters. But I could not success.
Can someone suggest me, why could not I see the break when there is an exception.
I want to break into the debugger, exactly at the time of exception.
Can I use SXE ud "dllName" in kernelmode to notify my when a perticula dll gets unloaded?
the exception was
Explorer Crash, "The instruction at 0x6ad88b5 refrernced memory at 0x0000000. The memory could not be read"
This should work:
Launch gflags.exe from WinDbg.
Go to "Image File" tab, type in "explorer.exe" and hit TAB key.
Check the first item "Stop on Exception".
Now when explorer.exe crash and kernel debugger is connected, WinDbg should break.
First, loading or unloading of DLL will not cause break when debugging in Kernel mode, they work well when doing user mode debugging however.
i believe in kernel mode debugging you should be able to break, when kernel mode binaries like .SYS file are loaded or unloaded.
Now, to your question. One way could be,
set Windbg as the default postmortem debugger. windbg.exe -I.
This will ensure that you break in the debugger when any exception occurs. But this would be user mode debugging.
Next, given that you have a KD setup, just executing .breakin, will take you form user mode to kernel mode debugging.
Italic are debugger commands.

Visual Studio debugging program locked in memory

When i am debugging my program and an error occur, the debug session ends, but the program remains in memory. Using the activity manager of Windows to close it does not work. I need to close Visual Studio in order to kill the process.
Why is this happening?
When during debugging a program error occurs, the program usually does not "end". Instead, the debugger (VS2010) pauses execution, allowing you to inspect the code resulting in the error. Depending on the language used (e.g. C#) and the way you compiled your program, you may even be able to edit the program on the fly, move the execution cursor back a bit and continue the program from there.
If the Debug toolbar is visible (in my case it shows up automatically whenever I'm debugging), you should see a couple of "playback" buttons, allowing you to start/continue, pause, stop your program etc. If you stop your program, it will be gone from the task manager too.
As I mentioned in a comment on your question, you can also use the Debug menu to accomplish these tasks.

What is the best way to debug a crashing explorer.exe?

I work for an orginization that has a custom built Access/SQL Application running in house. We have a problem Explorer.exe throwing an error and crashing.
This is a picture of the crash:
What is the best way to start tracking this problem down and finding a solution ?
Make sure WinDBG is installed, set it up as the default debugger then use Analyze and get a crash dump.
The next time you get that dialog click "OK" to attach in WinDbg
Keep in mind that if you attach a debugger to explorer, then break, that you should not try to do anything in the debugger that invokes a call to explorer or you will deadlock the debugger. This can be surprisingly tricky as it means you cannot open a "File Open" dialog, print, browse to another computer and any number of other things.

Resources