It is very common for me to query the meaning of an NTSTATUS value.
However, I always get nothing by the WinDBG command !error like the following:
kd> !error 0xC0000008 1
Error code: (NTSTATUS) 0xC0000008 - Unable to get error code text
Why does the WinDBG command !error not work as expected?
Thanks in advance.
PS. 0xC0000008 indicates STATUS_INVALID_HANDLE
Probably you should set locale
for example:
0: kd> .locale ".1251"
http://perfect-coding.blogspot.ru/2011/06/windbg-error-extension-and-locale.html
Related
I have been trying to get a w3wp crash dump to see the crash callstack. I got two dumps but both of them have a single thread in them - seems almost like AppDomain has been recycled already and there is nothing useful left in the process when the dump was saved.
Command used: "procdump -mm -e -n 1 -l pt <PID>"
Also tried -ma for full dump but result is the same:
0:000> ~
. 0 Id: fa4.1dc8 Suspend: -1 Teb: 000000b1`77a78000 Unfrozen
I am not sure if I am missing something in the command, or IIS does not provide usable managed dumps when capturing them with procdump - any inputs are highly appreciated!
Additional detail: I was seeing STACK_OVERFLOW exception being logged by the procdump, which - apparently needs different method to capture useful dump. See my own answer below for details.
It only took few hours - hopefully this will save some time for others like me.
Found a way to do this:
procdump -mm -e 1 -l -f C00000FD.STACK_OVERFLOW -g <PID>
It works! Thanks to the unknown fellow member whose hint lead me to this. I was reading too many pages and missed saving the page link to post acknowledgement here.
I'm trying to understand the mechanics of loading an executable file, so I did two different tests with notepad.exe
1) Running dumpbin command:
dumpbin /ALL "C:\Windows\System32\notepad.exe" /OUT:"C:\sample\log4.txt"
I got the following values under OPTIONALHEADER VALUES:
1AC50 entry point (000000014001AC50) WinMainCRTStartup
1000 base of code
140000000 image base (0000000140000000 to 0000000140042FFF)
2) Running WinDbg:
x notepad!*CRT*
I got these:
00b9bf9a notepad!__mainCRTStartup (void)
00b9bf90 notepad!WinMainCRTStartup (<no parameter info>)
00ba04a4 notepad!msvcrt_NULL_THUNK_DATA = <no type information>
00ba050c notepad!_IMPORT_DESCRIPTOR_msvcrt = <no type information>
I don't understand why 14001AC50 and 00b9bf90 are different values. Shouldn't they be the same AddressOfEntryPoint value?
Thanks in advance
There are a couple reasons for the discrepancy.
First, you are running dumpbin on the x64 version of notepad.exe, stored in System32 but you seem to be debugging the x86 notepad.exe stored in SysWoW64. Make sure you've launched the x64 or AMD64 version of WinDbg and that you're attaching to C:\Windows\System32\notepad.exe.
Once that's sorted out things should start making more sense but there's one more thing to keep in mind. The x command in WinDbg is displaying the virtual memory address of the symbol in the running process while dumpbin displays it as an offset from the module base address.
Some quick subtraction from the module base and things should match up.
Here's how it looks on my system:
C:\>dumpbin /ALL "C:\Windows\System32\notepad.exe" | find "entry point"
1AC50 entry point (000000014001AC50) WinMainCRTStartup
0:000> x notepad!WinMainCRTStartup
00007ff6`4fe1ac50 notepad!WinMainCRTStartup (<no parameter info>)
0:000> ? notepad!WinMainCRTStartup - notepad
Evaluate expression: 109648 = 00000000`0001ac50
I'm having problems trying to connect in my oracle database using an ADODB object in VBScript, the code is working on a Win7 machine but not on WinXP, I tried to search for the error code, downloaded the sdk with the help file to look for something but I didn't found nothing useful.
Here is the code sample:
ConnectionString = "DSN=(Oracle in OraClient11g_home1);UID=username ;PWD=password ;DBQ=myDatabase"
Set objCon = CreateObject("ADODB.Connection")
objCon.Open ConnectionString 'the error occurs in this line
I don't know if the connection string must be different for winXP machines... I really don't know how to solve this, can someone help me?
The error trace information:
"Error #-2147024770:
Error reported by: ADODB.Connection
Help File:
Topic ID: 1240640"
-2147024770 = FFFFFFFF8007007E
To Decode 0x8007nnnn Errors
HResults with facility code 7 means the HResult contains a Windows' error code. You have to look up the Windows' error code not the HResult.
To decode 0x8007007e. The 0x means it's a hexadecimal number, the 8 means error, the first 7 means it a windows error, and the rest of the number, 7e, is the actual Windows error.
To look up the error we need it in decimal format. Start Calculator (Start - All Programs - Accessories - Calculator) and choose View menu - Scientific, then View menu - Hex. Enter 7e. Then View menu - Decimal. It will say 126.
Start a Command Prompt (Start - All Programs - Accessories - Command Prompt) and type
net helpmsg 126
and it will say
The specified module could not be found.
or look it up in winerror.h
//
// MessageId: ERROR_MOD_NOT_FOUND
//
// MessageText:
//
// The specified module could not be found.
//
#define ERROR_MOD_NOT_FOUND 126L
To see what is happening start your program in ntsd.
Start a command prompt.
Type
md c:\symbols
set _NT_SYMBOL_PATH=srv*C:\tmp*http://msdl.microsoft.com/download/symbols;c:\symbols
then (changing it to your program from notepad)
ntsd -g -o c:\windows\notepad.exe
so something
ntsd -g -o wscript "c:\folder\script.vbs"
and wait for the error.
Looks ProcDump dumps a post mortem dump of the wrong thread. Made ProcDump the JIT-debugger:
C:\>procdump -ma -i c:\mydumps
Made a test program C++ MFC:
int* ptr = 0;
switch(message) {
...
case IDM_CRASH:
*ptr = 23;
break;
...
Selecting the Crash item from the menu (of the program ProcDumpTest.exe), the application crashes and a dump is made. The dump however shows (windbg) a stack and an instruction pointer (eip = 7c90e514) of an unexpected thread. How to get the stack trace of thread where the error occurred?
00400000 - 004a0000 ProdDumpTest.exe
07c90000 - 07c9b000 ntdll.dll
Got the same problem in a more serious case. Thanks for any help! GMore
After the .reload /f command, the !analyze -v showed the correct information. Thanks for the help.
In the book "Rootkit Arsenal" page 84 (Chapter 3) mentions:
..., we can view the contents of the
target machine's descriptor registers
using the command with the 0x100 mask:
kd> rM 0x100
and a paragraph below:
Note that the same task can be
accomplished by specifying the GDTR
components explicitly: kd> r gdtr ....
I run Windbg on my Win XP (inside VMWare) and choose the Kernel Debug -> Local.
My problem is in case of first command, windbg errors with:
lkd> rM 0x100
^ Operation not supported in current debug session 'rM 0x100'
and in the second command:
lkd> r gdtr
^ Bad register error in 'r gdtr'
Can anyone guide me ?
Right, you can't look at registers in a local kernel debug session. LiveKD works and you can also get the address indirectly through the PCR (!pcr).
-scott
I think I've found the solution:
Use two computers for kernel debugging instead of Local Kernel Debug.
(I used VMWare and am debugging through the COM port/named pipe)
I am thinking why this facility/feature (Local Kernel Debugging) is there if it's not complete ?