I am debugging a driver in a VirtualBox VM, with WinDbg attached to the target via COM port exposed to the host as a named pipe.
Debugging works fine - I can pause the target, set breakpoints, step through source files .etc
When my driver encounters a fatal error WinDbg dumps the following output to the console:
*** Fatal System Error: 0x00000050
(0xFFFFF88004126840,0x0000000000000001,0xFFFFF88003E12690,0x0000000000000000)
Driver at fault:
*** MYDRIVER.sys - Address FFFFF88003E12690 base at FFFFF88003E12000, DateStamp 51249ae5
.
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows 7 7601 x64 target at (Wed Feb 20 09:57:54.670 2013 (UTC + 0:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
..............
Loading User Symbols
.....
Loading unloaded module list
.....Unable to enumerate user-mode unloaded modules, Win32 error 0n30
Loading Wow64 Symbols
..........................................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 50, {fffff88004126840, 1, fffff88003e12690, 0}
The little status box on the debugger command line is blank, and the debugger does not respond to the commands I type in.
I want to see the call stack and inspect the machine state, but the debugger remains unresponsive. Pressing BREAK/CONTINUE seems to have no effect.
I don't understand - what is the state of the debugger at this point?
I have a suspicion that my whole debugging setup is just very, very slow.
Debugging via com port is very slow, you must switch to virtualkd - http://virtualkd.sysprogs.org/ (its use shared memory between host and guest and much much faster). And don`t press anything while you waiting, its slow down process a little bit more.
In general com is outdated and while debugging, without vm, all use firewire or usb interfaces.
Related
I am trying to find all the functions including both user mode functions and kernel mode functions that wmic.exe calls to execute the diskdrive command. In order to do this I opened wmic.exe in my virtual machine and set breakpoint in kernel mode windbg on WMIC!CParsedInfo::GetUser and WMIC!CExecEngine::ExecuteCommand.
As soon as I input diskdrive debugger breaks on ExecuteCommand, I am in kernel mode through COM port, but I cant use wt command, however I can run instructions line by line and step in to every call and track all function in stack call, but this will take lots of time and it’s not optimized. Is there any way to do something similar to the wt command in the kernel debugger?
Whenever I use the wt command it outputs ^ Unimplemented error in 'wt'.
Some extra info:
I am running Windows 11 Enterprise Build 22000.856 on VMWare and connected to it through the COM port for kernel debugging and the host OS is the latest version of Windows 11 Enterprise.
Windbg is also the latest version of windbg.
Both windbg and vmware running as administrator.
I am able to use all the usual commands I can see registers, see stack calls with single step, see threads and etc.
wt runs normally on my main OS for user mode processes on my main OS without any problem
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.
When I clicked the X button to close a program (say it is MYAPP), a dialog popped up saying:
MYAPP has stopped working
Windows can check online for a solution to the problem."
But actually the application had already exited.
Error info:
Problem signature:
Problem Event Name: APPCRASH
Application Name: MYAPP.EXE
Application Version: 1.0.0.0
Application Timestamp: 56a8dfa8
Fault Module Name: MSVCP90D.dll
Fault Module Version: 9.0.30729.6161
Fault Module Timestamp: 4dace5bf
Exception Code: c0000005
Exception Offset: 00007b3f
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 3081
How does Windows detect if a program is "stopped working"? Does it indicate the application throws an exception or a dead lock?
Windows Error Reporting (WER) will catch unhandled exceptions. It won't catch a deadlock. That dialog box that pops up when a program "stops working" is a WER crash-dump being taken (or it communicating with a MS server to see if it wants to take a crash-dump, etc.).
There are several ways to debug a crashing program that are tried and true (although arduous). Some of these include:
Using GFlags to launch Visual Studio or WinDbg
Including code in the program to launch a debugger
In this case with WER, you could turn on local crash dumps, and then, as long as you have the symbol database (pdb) file, you can debug from a local crash dump. You can read more on taking local crash dumps at Collecting User-Mode Dumps.
I'm using windbg to analyze a memory dump on a separate computer from where the dump file originated. Inside the tool's commmand line, I typed in the following:
.loadby w3core w3core
Here's the error:
The call to LoadLibrary(c:\windows\system32\inetsrv\w3core.dll) failed, Win32 error 0n126 "The specified module could not be found." Please check your debugger configuration and/or network access
Update: The process which I create the dump file from is w3wp.exe. I think that is for IIS. It's the IIS Worker Process. So, w3core.dll must be related to the IIS Worker Process.
Just to review my steps, I used the Debug Diagnostic Tool to monitor a crash of a particular process on Computer A. (Computer A is running Windows Server 2003 Standard 32-bit, IIS 6; ASP.NET is NOT installed.) This crash created a memory dump file. I copied this dump file to Computer B, which has Debug Diagnostic Tool and windbg installed. On Computer B, I added the dump file in the Advanced Analysis tab of the Debug Diagnostic Tool and clicked the "Start Analysis" button. The analysis summary reported:
the module c:\WINDOWS\system32\inetsrv\32.core.dll has caused an access violation
exception(0xC0000005) when trying to read from memory location 0x53534553 on thread 4
I opened windbg and added the Symbol File Path
SRV*downstream_store*http://msdl.microsoft.com/download/symbols
Then, I opened the dump file and typed in the above command and it spit out the aforementioned error. I can assure that the file definitely exists.
What is the problem? Is it because I'm debugging on Computer B, when, in fact, the dump file came from Computer A? Beyond that, I'm not sure what I'm doing wrong.
Why can't I load this module? Thank you very much for any help.
Try loading w3core in depends (http://www.dependencywalker.com/) assuming you can find the dll (which if you can't would also explain it). If it is missing any dependent dlls it should show you there.
I am new to driver stuff. I have tried to debug the kernel driver using serial COM port without success. Could someone show me proper direction how to fix the problem?
I am seeing the following messages on kd console.
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
At this time, I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
EDIT: The problem is fixed with WinDbg. I changed the baud rate to 115200 and inserted break (Ctr ^ Break) before Target system completely boots up. I am able to debug the code now. If I insert break after the target system completely boots up then I am unable to debug. I don't know exact reason for it but Happy with current situation.
Here are the things I have done
1) Prepared Target system for debug mode by editing the boot.ini file. Added “/debugport=com1 /baudrate=57600” to boot.ini
2) On Host system, started kd.exe and seeing the following output
C:\Program Files\Debugging Tools for Windows>kd.exe -k com:port=1,baud=57600
Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\com1
Waiting to reconnect...
3) Rebooted Target system, system boots slowly than normal boot and I am seeing some messages <<below>> on Host system console
4) At this time, If I press Ctl-C on KD console then Target system freezes (hangs) and proceeds if I enter "g" at kd prompt. This means that Target system is going to debug mode
5) However After some time I am seeing the following message on the host machine console
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
After the above message there are no messages appearing on kd console.
I searched internet for "ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127" but didn't get proper reason for it.
I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
I have tried above steps with following options ..but no luck
I disabled firewall & antivirus software on both Host and Target systems.
I unplugged and re-plugged serial cable connection between each trail
I have logged-in with Domain account local account with Admin rights
Can someone show some light on how to proceed? Both systems are running on XP 32bit SP3 OS.
Thanks
King
Are you sure you have a good serial connection?
The cable must be a null modem cable - you should verify this using a terminal program (without kernel debugging enabled on the target). Run the program (HyperTerminal or whatever) on both the target and the host machines (remember, like I said before kernel debugging over that port must not be enabled on the target or the port can't be opened).
You can find some links to free terminal programs (I don't think Microsoft provides HyperTerminal anymore since Vista) here: http://www.lvr.com/serport.htm#software
Type some characters on one machine, and make sure they show up on the other side. Do the same on the other machine.
If you can't do this, then there's no serial connection and you'll have to get a null modem cable or adapter. There's no point in trying to get KD to work over that connection until you can do this.
Also, remember that the COM port used by kernel debugging on the target must be a standard 8250 family UART (usually a 16550 or better nowadays, and usually baked into the motherboard chipset). It can't be a USB serial port connector (although that kind will work fine on the host side, since on the host kd.exe is a regular Win32 program).
Edit:
If it's not a serial connection problem, the problem might be that your target doesn't support configuration using boot.ini. Since Vista, boot parameters have been specified using the "Boot Configuration Database" (BCD) which is manipulated with a program like bcdedit.exe. Unfortunately, configuring a system using BCDedit is much more complicated than just editing a simple text file like boot.ini.
You should read the debugger helpfile section "Configuring Software on the Target Computer"; in particular the "Using Boot Parameters" part. there are details there on how bcdedit can be used to enable debugging on Vista and later systems.
The other thing you can test to see if debugging is working on the target is to invoke kd -kl on the target - if it tells you debugging isn't enabled, you haven't set up boot.ini correctly.