I have the following scenario:
Windows 2008
A Service running running with a specific user credential (i.e. not the System Account).
That service starts a child process
The child process starts, gets an exception after a second and crashes
I am trying to attach a debugger to the child process and debug it before it crashes
I was trying to use gflags and set the debugger. Problem is that the service is running in session 0 hence Windbg is not viewable. I cannot set the service to "allow interact with desktop" as the service cant use Local System account but rather has to use credentials of specific user.
I wasn't sure if it is intended to work like that, but I also tried to connect to that windbg in session 0 from another instance of Windbg using Windbg -pe (so I would have two Windbg running). But it doesn't work - the second instance doesn't seem to be able to stop the process and see its call stack.
Any ideas how to attach a debugger to the child process before it crashes to debug it?
You can use the command line debugger cdb for that.
Start your service with cdb attached, and launched as a debugging server.
You can add the following command
"c:\program files\debugging tools for windows\cdb" -server
tcp:port=5500 -g -G
to the registry value Debugger (type string) of the registry key
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\YourApplication.Exe
Then use windbg to connect to the debugging server with
windbg -remote tcp:server=localhost,port=5500
One more option:
When WinDbg is automatically launched, you indeed can't see it. You can, however, configure ntsd as your jit debugger, and enable remote debugging. Then, you can connect your WinDbg to ntsd and remote debug the process. See for details: Debugging a Service on Windows Vista.
Why not start from crash dumps? http://www.codeproject.com/KB/debug/automemorydump.aspx
Add Sleep(30000) to your child process entry point. That will give you enough time to connect with the debugger.
Related
I want to log all system calls from winlogon.exe. I have already setup up connection between WinDbg on the host computer and kernel debugger in virtual machine, and every thing work perfect, except one thing - I cannot load logexts extension, which can be used to log all system calls. The problem is when I am trying to load logexts, I get a error:
> .load logexts
The call to LoadLibrary(logexts) failed with error 2.
Please check your debugger configuration and/or network access
I tried to debug notepad.exe, and this extension worked perfectly, so I think problem not in debugger itself. My question is can I log system calls in WinDbg by myself, without any additional libs, such as logexts?
Logexts is an extension for user mode and does not work in kernel mode. From WinDbg help:
One way to activate Logger is to start CDB or WinDbg and attach to a user-mode target application as usual. Then, use the !logexts.logi or !logexts.loge extension command.
(emphasis mine) and also
[...] that loads and initializes Logexts.dll in the target application process.
WinDbg's help does not mention "kernel" anywhere near logexts.dll.
I have Windbg set as the default post mortem debugger. I did this by running windbg -I. However, this only appears to catch unhandled exceptions from applications run by the user I'm logged on as, not Windows services. Does anyone know how I can configure windbg to catch these too?
If you plan to debug the service application from the beginning of its execution, including its initialization code, this preparatory step is required.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553427(v=vs.85).aspx
When WinDbg is running as postmortem debugger it is launched by the process that is crashing. In case of a service it is launched by a process running in session 0 and has no access to the desktop.
You can configure AeDebug registry to launch a process that creates a crash dump and debug the crash dump. You can use ntsd -server and connect to the server.
You should be able to use WinDbg to attach or launch any service even those not run by the user: http://support.microsoft.com/kb/824344
My winform application crashes as soon as its been launched. This problem is only happening in one of the client computer. Works fine for all other clients. I was thinking of using ADPlus to get a crash dump but problem is in order to configure ADPlus in crash mode, debugger need to be attached to running application first. That means application must be running when I configure ADPlus, however, as I said my application crashes as soon as I start it. It does not give me a chance to run ADPlus. Any idea if ADPlus can be used in this scenario? Are there any other tools that I can use generate a process dump in this case?
Since you can't start the program and then attach a debugger in time, you can try one of the following ideas:
Start the program under the debugger on the machine where it's crashing. As already mentioned, ProcDump is enough for that purpose, or you can use Visual Studio or WinDBG.
If you can't easily start the program under the debugger (for example, if it is actually a Windows service), use gflags to make Windows start the program under the debugger. This will create a subkey for your program filename under the Image File Execution Options registry key.
Set your debugger as the postmortem debugger, so it always launches when any program crashes.
If and when the crash happens, the debugger will automatically break in and either create a dump automatically or let you create one manually.
If you can't run a debugger, not even ProcDump, you can use Windows' built-in crash dump facility to create a dump automatically:
On Windows XP and Windows Server 2003, set Dr. Watson as the postmortem debugger by running this command:
drwtsn32 -i
Here is info on what this command does and how to use Dr. Watson: Capturing Application Crash Dumps
On Windows Vista SP1, Windows Server 2008, and later, set Windows Error Reporting to save dumps locally by creating this registry key:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
You don't need to create or set any values or subkeys under this key. If you want to change settings, here is more info: Collecting User-Mode Dumps
Note that "applications that do their own custom crash reporting, including .NET applications, are not supported by" WER. This is a problem for you because your app uses WinForms - although there is some indication that the feature does work with .NET 4 apps on Windows 7.
You can use ProcDump from Sysinternals to capture a dump.
I set up my development environment on a widows server 2008 r2 machine. The problem is that whenever a process that is running in session 0 crashes, i get absolutely no notification of it. No Windows error reporting, no visual studio jit debugging prompt. If a regular application crashes, then i get the jit debugging popup and am able to attach the debugger fine. What could be going on?
In W2K8 session 0 services run with no UI (non interactive). Therefore you'll never get a popup. One way around this is to set your AEDebug regkey to attach either ntsd or cdb with remote debugging, something like ntsd.exe -server tcp:port=50000:54999 -p %ld -e %ld -g -noio. Then when something crashes, you will see the ntsd.exe process running in taskmgr and you can attach to it (you'll need to use cdb and query which ports are open for debugging). This can easily be wrapped in some sort of daemon process or service that's continuously monitoring for new debugging sessions and automatically pop up cdb for you.
You can then extend this pattern to launch an arbitrary logging process instead of ntsd. Just make sure the process is running with the right permissions and no UI.
I'm trying to attach to a remote machine with code similar to the following:
Debugger2 db (Debugger2)dte.Debugger;
Transport trans = db.Transports.Item("Default");
Process2 proc2 = (Process2)db.GetProcesses(trans, "MACHINENAME").Item("SERVICENAME");
proc2.Attach2();
I've gotten it to work by logging on through remote desktop and manually starting the debugger, but I have to stay logged in. The problem is, I don't want to stay logged into the remote machine. Is there a way to automatically launch the debugger, similar to what happens when I attach through the IDE?
You could wrap your debugging code as a Windows service that executes at startup with hightened privileges.
However, I don't recommend that route, because based on experience I think it's over-kill for what is most likely needed. Could you expand on why you want to attach a debugger to a remote process automatically?
My guess is that you want to do something that would be best suited for WinDbg. Something similar to these.
Enabling windbg to break on clr exceptions
Configuring a service to start with windbg debugger attached
But, without more background information on what you are trying to accomplish, I'm obviously just guessing.