debugging program that is a child of Microsoft Word - debugging

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...

Related

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.

How to attach a Visual Studio debugger to a Managed type process?

I've been following this guide to debug a Windows Service application.
Basically, I need to attach the Visual Studio debugger to the process started after installing the Windows Service that has been developed. However, VS doesn't allow me attach the debugger to this process as shown in the following picture:
How can I attach the debugger to this process? If I clicked on any of the other processes the Attach button becomes enabled.
Any help would be greatly appreciated
check the checkbox Show processes from all users, then you will see AutomatedReports.exe. Attach that (not AutomatedReports.vshost.exe)
vshost is a host process to help with the debugging. More info on this MSDN Link
Also you need to place the following line in your service code where you want to hit the break point.
System.Diagnostics.Debugger.Break();
The service is probably running on a separate user account. Check the "Show processes from all users" checkbox and attach the debugger to AutomatedReports.exe process.
Also make sure that you are running a Debug build of the service, otherwise, you won't be able to debug a lot.
Have you tried to change the type of the code you are debugging?
Click on "Select ..."
Select "Debug these code types"
You can then select Types like: “Managed (v4.0…)"

Process is disabled in VS2010 attach to process dialog

I have a VS2010 running on a WTS machine (Windows2008).
I'm trying to attach the debugger into a process. The process is running a WPF client.
The process is presented in the attach to process dialog, but grayed out and the attach button is disabled.
I read through the discussions, and confirmed managed code is enabled for debugger, with no luck. Here are two screenshots representing the current situation (in the first image, the process I'm trying to debug is marked in blue - please note I'm running as admin):
snapshot goes here - but was removed by stack overflow...
After trying the automatic code type selection, I tried the manual way, with no luck. Here is the screenshot:
snapshot goes here - but was removed by stack overflow...
Any help would be appreciated.
Thanks,
Busi
Perhaps you are already attached to the process? Did start debugging before attaching to the process?
Found another cause/solution to this problem, select the 'Show processes from all users' and 'Show processes in all sessions' check boxes and I got two instances of my service, one greyed out (which was always visible) and another I could attach to. hth :).
I ran into the same issue with my windows service.
I could not attach to a running windows service that I built.
My solution has multiple projects with the windows service as the startup project.
I found out that my problem is caused by having the startup project is the same as the windows service.
To solve my problem, I just set a different project as the StartUp Project.
I'm not certain, but there may be a debugger already attached to the process, and that's why Visual Studio won't let you attach it. Are you certain that you're not running the application already in debug mode or do you have another VS instance running?
If you are trying to attach a web service or web app (w3wp.exe) then, try resetting the iis (iisreset). It worked for me.

Why can't I attach to the w3wp.exe process when I turn off Just My Code in VS2010?

I'm using VS2010 Beta 2 and I turned on .NET Framework source stepping, so I had to disable 'Just My Code'. But now the w3wp.exe process doesn't show up in the list of processes I can attach to. I've got both show all processes boxes ticked. Is this a bug or am I missing something?
Make sure you have the Show processes in all sessions checkbox checked!
Ok, I found how to make it work, I rebuilt the whole solution and it started seeing the process again. This doesn't make a whole lot of sense to me, but oh well.
I fixed this by clicking Debug > Start Debugging, then once it starts up click Stop Debugging. Then I returned to the Attach to Process dialog and W3WP was in the list again.
Are you sure that the w3wp.exe process didn't die while debugging? Does it show up in Task Manager?
I couldn't find the process because the web page was still showing an error dialog and hadn't finished processing.
Make sure you have ended the previous debugging session (and run the web code to the end).
Closing Visual Studio did not help, the same goes for restarting IIS and rebuilding the solution.
As long as I was, some weird way, still attached to w3wp it did not show up in the attach list. Once I made sure the web page had finished and no dialogs of any kind was open, w3wp returned again.
You might need to be a member of the Administrators/Local Admins group for your machine.
Had this happen to me on one of our VMs today. Closing, re-opening VS2010 made no difference, rebuilding the website (!) made no difference.
But I logged out, logged in as administrator, added myself to the Administrators group, logged out, logged back in as myself, and once every application was loaded up -- I could get w3wp.exe appearing in the processes list for attaching.
In the absence of some other confirmation, it is possible that the act of logging out/logging-in again did the trick all by itself.
Try restarting Visual Studio. This worked for me.

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