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.
Related
I'd like to use Ollydbg2 to debug FLTLDR.EXE, which is spawned when my document is opened in Microsoft Word. I can't run FLTLDR.EXE manually I don't think, it seems to need to be run or hosted by Word.
I have ticked the "Debug child processes" in Olly and tried to debug Word, but an exception is raised before I can even open the document.
Any ideas?
Many thanks
For this you have to create a registry key to tell the OS that you want your app, FLTLDR.EXE, to be started with a debugger attached to it.
Follow the steps in the link:
https://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx
After setting the registry key just launch Word application. The execution of FLTLDR.EXE causes the ollydbg to start automatically. From this point you can continue debugging.
side note: receiving exceptions while attaching to some application with the debugger is normal. Most of the time Shift+F9 solves the problem and you can continue but if it's happening several times on a same address you can save the exception address and then Shift+F9...
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.
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.
Is there any way to use the "Run As" option in Windows XP in conjunction with Visual Studio's debugger, to debug an issue that occurs in my application only when certain users are logged in?
I have ran the application from my machine using "run as" to pretend to be the user in question, and I got the same error as they did. I would like to debug this error and see where and what exactly is causing it. The error occurs specifically when a certain domain user is logged in, and never otherwise.
Is there any script or approach I can take to debug this error; that is too launch the application, as the problem user, and then use the debugger?
Trying to attach to the process didn't work since it was a C# managed process and VS didn't let me attach.
The first two options that come to mind are...
Log onto the machine as the user (simplest approach)
Right-click on the Visual Studio executable and run as that user.
I think that you could edit the .config file to use impoersonation, but I'm not sure if that will result in the app running truly the way it would for the user.
Although with good error handling, the error message itself should be enough to tell you where in the code the problem is... At the very worst, you could compile it in debug mode (so you have all the symbols) and add some global error hanlding and get the exact stack trace...
I use David Strattons second solution (run as Administrator) because my application requires administrator privileges (-> elevated).
Another solution could be to start the application as the user and use "Debug | Attach to process..."
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.