Weird stack

[OSR_Community_User]

So I built a tiny test app, and I see the exact same problems. This is with all the default settings for VS2008, SP1. How is anyone debugging on x64? Is no one else ever seeing these issues?

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 1:41 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes this is the latest release. I know the PDB is loaded, but the !lmi output says that the debug data is not mapped, which is what I meant. If I connect to the process with Windbg from user-mode, it apparently maps it no problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped and the kernel mode debugger not being able to get to it. Now I thought specifying the image path would help this, since Windbg could just read the debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest release?

• S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly. Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break* because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break* because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

And it also occurs when debugging a 32bit WOW64 app too.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 5:47 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

So I built a tiny test app, and I see the exact same problems. This is with all the default settings for VS2008, SP1. How is anyone debugging on x64? Is no one else ever seeing these issues?

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 1:41 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes this is the latest release. I know the PDB is loaded, but the !lmi output says that the debug data is not mapped, which is what I meant. If I connect to the process with Windbg from user-mode, it apparently maps it no problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped and the kernel mode debugger not being able to get to it. Now I thought specifying the image path would help this, since Windbg could just read the debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest release?

• S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly. Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break* because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break* because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

>Now I thought specifying the image path would help this, since Windbg could

just read the debug data from the local image on disk.

Image path is only there for minidumps, I don’t think that WinDBG uses it
for anything else.

I’m assuming that the address of the exception directory is a correct RVA
based off the image start so:

Not always. For example, I have an app loaded at 400000

0000000000400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.00 operating system version
6.00 image version
5.02 subsystem version
7000 size of image
400 size of headers
92BD checksum
…
0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

400000+5000 is bogus:

1: kd> dc 00400000+5000
0000000000405000 ???????? ???????? ???????? ???????? ???????????????? 0000000000405010 ??? ??? ??? ??? ???

But the exception directory info is valid, just at a different address:

1: kd> .fnent canclapp!main
Debugger function entry 00000000007293f8 for: c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69) (00000000004018e0) canclapp!main | (00000000`00401c80)
canclapp!Reader
Exact matches:
canclapp!main (unsigned long, char **)

BeginAddress = 00000000000018e0 EndAddress = 0000000000001c76
UnwindInfoAddress = 00000000`00002bb0

Unwind info at 0000000000402bb0, 10 bytes version 1, flags 3, prolog 22, codes 2 frame reg 0, frame offs 0 handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178
00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188

(Note the “Unwind info at 00000000`00402bb0”)

It’s easy to do the actual translation programmatically with
ImageDirectoryEntryToDataEx, though I don’t know a quick way to do it in the
debugger. Maybe someone knows an extension command that would do it.

What happens if you !pte mydll+26474c?

It’s certainly all a mystery. I don’t do much user mode stuff though and I
don’t use VS, so I might not be the best to comment on how prevalent this is
(first time I’ve seen it).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jeff Curless” wrote in message news:xxxxx@windbg…
Yes this is the latest release. I know the PDB is loaded, but the !lmi
output says that the debug data is not mapped, which is what I meant. If I
connect to the process with Windbg from user-mode, it apparently maps it no
problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped
and the kernel mode debugger not being able to get to it. Now I thought
specifying the image path would help this, since Windbg could just read the
debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest
release?

- S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being
mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t
validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search
path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA
based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com <br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly. <br>Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the <br>exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com <br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break* because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break* because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

I doubt that I recreated your exact scenario, but I couldn’t reproduce either the x64 or WOW64 case of a simple VS2K8SP1 app (console) on Win 7 RC x64 under 6.11.1.404 x64.

Actually, I know I didn’t reproduce it exactly - I notice that you’re using delay loading in your ‘mydll.dll.’ I’m not sure how windbg feels about this, but it seems like it might be relevant.

Hopefully someone from the windbg team might be able to comment on this.

Good luck,

mm

[Ken_Johnson]

The RVA is right - and yes, adding the RVA to the image base is all that’s required. The exception directory points to an array of RUNTIME_FUNCTION structures which contain RVAs to the actual unwind info, which do not necessarily need to reside within the exception directory.

In your case, the debugger seems to be using the fallback logic to successfully pull this information from symbols data. This is what *should* be happening for the OP.

I don’t know why this fallback isn’t working for the OP yet, unfortunately. I haven’t repro’d this problem locally, but I’m only really looking at this in my spare time either.

• S

-----Original Message-----
From: Scott Noone
Sent: Wednesday, June 24, 2009 08:20
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

>Now I thought specifying the image path would help this, since Windbg could
>just read the debug data from the local image on disk.

Image path is only there for minidumps, I don’t think that WinDBG uses it
for anything else.

>I’m assuming that the address of the exception directory is a correct RVA
>based off the image start so:

Not always. For example, I have an app loaded at 400000

0000000000400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.00 operating system version
6.00 image version
5.02 subsystem version
7000 size of image
400 size of headers
92BD checksum
…
0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

400000+5000 is bogus:

1: kd> dc 00400000+5000
0000000000405000 ???????? ???????? ???????? ???????? ????????????????<br>0000000000405010 ??? ??? ??? ??? ???

But the exception directory info is valid, just at a different address:

1: kd> .fnent canclapp!main
Debugger function entry 00000000007293f8 for:<br>c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)<br>(00000000004018e0) canclapp!main | (0000000000401c80)<br>canclapp!Reader<br>Exact matches:<br> canclapp!main (unsigned long, char **)<br><br>BeginAddress = 00000000000018e0
EndAddress = 0000000000001c76<br>UnwindInfoAddress = 0000000000002bb0

Unwind info at 0000000000402bb0, 10 bytes<br> version 1, flags 3, prolog 22, codes 2<br> frame reg 0, frame offs 0<br> handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178
00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188

(Note the "Unwind info at 0000000000402bb0")<br><br>It's easy to do the actual translation programmatically with<br>ImageDirectoryEntryToDataEx, though I don't know a quick way to do it in the<br>debugger. Maybe someone knows an extension command that would do it.<br><br>What happens if you !pte mydll+26474c?<br><br>It's certainly all a mystery. I don't do much user mode stuff though and I<br>don't use VS, so I might not be the best to comment on how prevalent this is<br>(first time I've seen it).<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>Yes this is the latest release. I know the PDB is loaded, but the !lmi<br>output says that the debug data is not mapped, which is what I meant. If I<br>connect to the process with Windbg from user-mode, it apparently maps it no<br>problem, which makes sense.<br><br>So this is probably an issue of the information being paged out/not mapped<br>and the kernel mode debugger not being able to get to it. Now I thought<br>specifying the image path would help this, since Windbg could just read the<br>debug data from the local image on disk.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 9:45 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No, it loaded symbols ("Symbol Type - PDB"). I assume this is the latest<br>release?<br><br>- S<br><br>-----Original Message-----<br>From: Jeff Curless <xxxxx><br>Sent: Monday, June 22, 2009 15:17<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: RE: Re:[windbg] Weird stack<br><br>Here is the info, looks like there is a problem due to debug data not being<br>mapped. Any idea how to fix that?<br><br>kd&gt; !lmi mydll.dll<br>Loaded Module Info: [mydll.dll]<br> Module: mydll<br> Base Address: 0000000180000000<br> Image Name: mydll.dll<br> Machine Type: 34404 (X64)<br> Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009<br> Size: 2da000<br> CheckSum: 0<br>Characteristics: 2022<br>Debug Data Dirs: Type Size VA Pointer<br> CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can't<br>validate symbols, if present.<br> Image Type: FILE - Image read successfully from debugger.<br> mydll.dll<br> Symbol Type: PDB - Symbols loaded successfully from symbol search<br>path.<br> e:\mydll\x64\debug\Mydll.pdb<br> Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]<br> Load Report: private symbols &amp; lines, not source indexed<br> e:\mydll\x64\debug\Mydll.pdb<br><br>kd&gt; !dh 0000000180000000<br><br>File Type: DLL<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 8 number of sections<br>4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 2022 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br> DLL<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br> 9.00 linker version<br> 1CAE00 size of code<br> 10AE00 size of initialized data<br> 0 size of uninitialized data<br> 10ECF0 address of entry point<br> 1000 base of code<br> ----- new -----<br>0000000180000000 image base<br> 1000 section alignment<br> 200 file alignment<br> 2 subsystem (Windows GUI)<br> 5.02 operating system version<br> 0.00 image version<br> 5.02 subsystem version<br> 2DA000 size of image<br> 400 size of headers<br> 0 checksum<br>0000000000100000 size of stack reserve<br>0000000000001000 size of stack commit<br>0000000000100000 size of heap reserve<br>0000000000001000 size of heap commit<br> 0 DLL characteristics<br> 295090 [173] address [size] of Export Directory<br> 2CE000 [3C] address [size] of Import Directory<br> 2D4000 [626] address [size] of Resource Directory<br> 2B3000 [179AC] address [size] of Exception Directory<br> 0 [0] address [size] of Security Directory<br> 2D5000 [2C08] address [size] of Base Relocation Directory<br> 1CD480 [1C] address [size] of Debug Directory<br> 0 [0] address [size] of Description Directory<br> 0 [0] address [size] of Special Directory<br> 0 [0] address [size] of Thread Storage Directory<br> 0 [0] address [size] of Load Configuration Directory<br> 0 [0] address [size] of Bound Import Directory<br> 2CE770 [730] address [size] of Import Address Table Directory<br> 2D0000 [1E0] address [size] of Delay Import Directory<br> 0 [0] address [size] of COR20 Header Directory<br> 0 [0] address [size] of Reserved Directory<br><br>I'm assuming that the address of the exception directory is a correct RVA<br>based off the image start so:<br><br>kd&gt; dq 0000001802b3000
00000001802b3000 ??????????? ???????????<br>00000001802b3010 ??????????? ???????????
00000001802b3020 ??????????? ???????????<br>00000001802b3030 ??????????? ???????????
00000001802b3040 ??????????? ???????????<br>00000001802b3050 ??????????? ???????????
00000001802b3060 ??????????? ???????????<br>00000001802b3070 ??????????? ???????????

Looks like it’s paged out.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 5:58 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes, that’s Bad™. That will cause stack tracing to behave incorrectly.
Do you have symbols loaded for mydll? (What’s !lmi mydll show?)

Can you read the exception directory (from !dh mydll – look for the
exception directory listing there to find its RVA and length) from mydll?

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No I don’t:

kd> .fnent mydll!myfunc
No function entry for 00000001800515f0<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Monday, June 22, 2009 4:53 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Weird stack<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>&gt;You should just use k instead of kv on amd64 as that is completely<br>&gt;unreadable.<br><br>It's important to have a really wide monitor when dealing with x64 dumps :)<br><br>I'm also entirely addicted to "kc" now, which shows a much more reasonable<br>call stack:<br><br>0: kd&gt; kc<br>Call Site<br>intelppm!C1Halt<br>intelppm!AcpiC1Idle<br>nt!PopProcessorIdle<br>nt!KiIdleLoop<br>nt!KiSystemStartup<br>0x0<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>&gt;Also if I do this:<br><br>&gt;Kd&gt; k<br>&gt;Child-SP RetAddr Call Site<br>&gt;000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]<br>&gt;000000000b29d698 0000000000000000 0x2a0f360<br><br>Very weird. If you do a<br><br>.fnent mydll!myfunction<br><br>Do you get a result?<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You should just use k instead of kv on amd64 as that is completely<br>unreadable. :( (Especially on a handheld screen!)<br><br>That being said, my guess is that you have an intervening frame for which<br>unwind information couldn't be pulled.<br><br>Unwinding on amd64 requires reading unwind metadata for each frame. This<br>can be problematic in kd because of things becoming paged out.<br><br>- If part of the loaded module list is paged out, or you did not load user<br>mode symbols beforehand, then the debugger won't have a binary for a given<br>frame's RIP and unwinding will break* because no unwind metadata can be<br>found.<br>- If symbols cannot be loaded and the unwind metadata for a binary is paged<br>out (not uncommon), then unwinding will break* because no unwind metadata<br>can be found.<br>- If you don't have symbol load notifications enabled (or otherwise weren't<br>there to get the notification at the time a particular binary was loaded),<br>and the image headers are paged out, then the debugger won't be able to get<br>unwind metadata and unwinding will break*.<br>- If the caller was JIT'd code, then unwinding will break* in kernel mode as<br>the kernel debugger doesn't support loading the JIT unwind helper DLL<br>(AFAIK).<br><br>*: I believe the debugger will treat these scenarios according to the<br>specification for a leaf function on amd64. This is going to be incorrect<br>for a function that isn't a leaf function.<br><br>In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your
first example), or mydll!myfunc3 000000000750d9e8 (your second example),<br>neither of which the debugger has associated with a loaded module. That<br>means the debugger probably gets lost at those respective frames because it<br>can't access the unwind table for those functions.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 12:56 PM<br>To: Kernel Debugging Interest List<br>Subject: RE:[windbg] Weird stack<br><br>Here is more. It appears to definitely be something to do with my PDBs as<br>the Microsoft ones from the symbol server look correct...<br><br># Child-SP RetAddr : Args to Child<br>: Call Site<br>00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78<br>000000000750d9d8 cccccccccccccccc : mydll!myfunc3<br>01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8<br>cccccccccccccccc 0000000007ab0d28 : 0x750d9e8<br>02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc<br>0000000007ab0d28 cccccc00cccccccc : 0x750d9e8<br>03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28<br>cccccc00cccccccc 00000001802b0268 : 0x750da78<br>04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc<br>00000001802b0268 cccccccccccccccc : 0x750d9d8<br>05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab0d28
07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc<br>08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe 000000000750d9e8 : mydll!myfunc2<br>09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc
0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8
000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc<br>0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8<br>cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc
0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000
cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe<br>0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x750d9e8<br>0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 000000000750dac0 : 0x750d9e8<br>0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>000000000750dac0 00000001800247f0 : 0xcccccccc00000000
10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0
00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc<br>11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0<br>0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc
12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60
000000000750da78 cccccccccccccccc : 0xcccccccccccccccc<br>13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78<br>cccccccccccccccc cccccccccccccccc : 0x750dac0<br>14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : mydll!myfunc1<br>15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 0000000007ab09a8 : 0xf6fd60<br>16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>0000000007ab09a8 cccccccccccccccc : 0x750da78<br>17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab09a8
1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc<br>1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc
1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc<br>cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc
1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc
0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc<br>20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680<br>000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe
21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f
0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc<br>22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760<br>0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc
23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827
00000000052f62b4 0000000000000400 : 0x7a99680
24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827
00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf
25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90
000007fefdb43a50 000007fefdb426d8 :
OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60
26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798
0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b
27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000
0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a
28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000
0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e
29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534
00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d
2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0
0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb
2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534
0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f
2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000
0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91
2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0
000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193
2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400
0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407
2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000
00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85
30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818
0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29
31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc
0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa
32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8
0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad
33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500
000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389
34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000
0000000000000000 0000000003440880 :
IEFRAME!CBrowserFrame::FrameMessagePump+0x411
35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801
00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d
36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98
37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df
38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

Thanks,
-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 3:47 PM
To: Kernel Debugging Interest List
Subject: [windbg] Weird stack

When I am kernel debugging on x64 and I am looking at a user-mode stack I
get a lot of funky output:

RetAddr : Args to Child
: Call Site
00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction2<br>00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction1
cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc
0000000000000000 : 0x2ad368<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccc`cccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Ken_Johnson]

Out of curiosity, did you perform a clean rebuild or are you using incremental/minimal rebuild?

• S

-----Original Message-----
From: Jeff Curless
Sent: Tuesday, June 23, 2009 15:00
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

And it also occurs when debugging a 32bit WOW64 app too.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 5:47 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

So I built a tiny test app, and I see the exact same problems. This is with all the default settings for VS2008, SP1. How is anyone debugging on x64? Is no one else ever seeing these issues?

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 1:41 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes this is the latest release. I know the PDB is loaded, but the !lmi output says that the debug data is not mapped, which is what I meant. If I connect to the process with Windbg from user-mode, it apparently maps it no problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped and the kernel mode debugger not being able to get to it. Now I thought specifying the image path would help this, since Windbg could just read the debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest release?

- S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly. Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break* because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break* because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

Yes I did a clean rebuild in the test app cases.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, June 24, 2009 5:40 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Out of curiosity, did you perform a clean rebuild or are you using incremental/minimal rebuild?

• S

-----Original Message-----
From: Jeff Curless
Sent: Tuesday, June 23, 2009 15:00
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

And it also occurs when debugging a 32bit WOW64 app too.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 5:47 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

So I built a tiny test app, and I see the exact same problems. This is with all the default settings for VS2008, SP1. How is anyone debugging on x64? Is no one else ever seeing these issues?

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Tuesday, June 23, 2009 1:41 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes this is the latest release. I know the PDB is loaded, but the !lmi output says that the debug data is not mapped, which is what I meant. If I connect to the process with Windbg from user-mode, it apparently maps it no problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped and the kernel mode debugger not being able to get to it. Now I thought specifying the image path would help this, since Windbg could just read the debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest release?

- S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly. Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break* because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break* because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

I believe he’s using /INCREMENTAL and -Gm.

I forgot to mention that when I posted about delay loading.

mm

[OSR_Community_User]

I’m not using either of those actually
I have /INCREMENTAL:NO

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@evitechnology.com
Sent: Wednesday, June 24, 2009 5:47 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

I believe he’s using /INCREMENTAL and -Gm.

I forgot to mention that when I posted about delay loading.

mm

---

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

My bad, Jeff. I guess I got this thread confused with another one that someone had posted their VS settings, or I was just wrong altogether.

Either way, sorry about that.

mm

[OSR_Community_User]

No biggie… I’m just confused as to why no one else seems to see this… sigh.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@evitechnology.com
Sent: Wednesday, June 24, 2009 6:24 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

My bad, Jeff. I guess I got this thread confused with another one that someone had posted their VS settings, or I was just wrong altogether.

Either way, sorry about that.

mm

---

WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

>The RVA is right - and yes, adding the RVA to the image base is all that’s

required.

Hmm…It’s been a while, but I wrote a test app for exploring this long ago
that I broke it out to verify before posting. It opens the file and memory
maps it as an EXE then dumps out the exception directory:

//
// Now get the exception directory from the image
//
exceptionTable = (PRUNTIME_FUNCTION)
ImageDirectoryEntryToDataEx(imageBase,
FALSE,
IMAGE_DIRECTORY_ENTRY_EXCEPTION,
&tableSize,
&sectionHeader);
Image base is 0x00390000:

0:000> !dh 0x00390000

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
4 number of sections
4A42B900 time date stamp Wed Jun 24 19:38:40 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

…

Exception directory is reportedly offset 0x5000:

0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

0:000> dc 0x00390000+5000
00395000 ??? ??? ??? ??? ???
00395010 ??? ??? ??? ??? ???

Exception table returned is 0x00392c00 :

0:000> dt exceptionTable
Local var @ 0x6ff60 Type _RUNTIME_FUNCTION*
0x00392c00
+0x000 BeginAddress : 0x1630
+0x004 EndAddress : 0x16b8
+0x008 UnwindData : 0x2ba0

If you step through ImageDirectoryEntryToDataEx you’ll end up in
ImageDirectoryEntryToData64 which does the calculation to return this
address.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
The RVA is right - and yes, adding the RVA to the image base is all that’s
required. The exception directory points to an array of RUNTIME_FUNCTION
structures which contain RVAs to the actual unwind info, which do not
necessarily need to reside within the exception directory.

In your case, the debugger seems to be using the fallback logic to
successfully pull this information from symbols data. This is what should
be happening for the OP.

I don’t know why this fallback isn’t working for the OP yet, unfortunately.
I haven’t repro’d this problem locally, but I’m only really looking at this
in my spare time either.

- S

-----Original Message-----
From: Scott Noone
Sent: Wednesday, June 24, 2009 08:20
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

>Now I thought specifying the image path would help this, since Windbg could
>just read the debug data from the local image on disk.

Image path is only there for minidumps, I don’t think that WinDBG uses it
for anything else.

>I’m assuming that the address of the exception directory is a correct RVA
>based off the image start so:

Not always. For example, I have an app loaded at 400000

0000000000400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.00 operating system version
6.00 image version
5.02 subsystem version
7000 size of image
400 size of headers
92BD checksum
…
0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

400000+5000 is bogus:

1: kd> dc 00400000+5000
0000000000405000 ???????? ???????? ???????? ???????? ????????????????<br>0000000000405010 ??? ??? ??? ??? ???

But the exception directory info is valid, just at a different address:

1: kd> .fnent canclapp!main
Debugger function entry 00000000007293f8 for:<br>c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)<br>(00000000004018e0) canclapp!main | (0000000000401c80)<br>canclapp!Reader<br>Exact matches:<br> canclapp!main (unsigned long, char **)<br><br>BeginAddress = 00000000000018e0
EndAddress = 0000000000001c76<br>UnwindInfoAddress = 0000000000002bb0

Unwind info at 0000000000402bb0, 10 bytes<br> version 1, flags 3, prolog 22, codes 2<br> frame reg 0, frame offs 0<br> handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178
00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188

(Note the "Unwind info at 0000000000402bb0")<br><br>It's easy to do the actual translation programmatically with<br>ImageDirectoryEntryToDataEx, though I don't know a quick way to do it in the<br>debugger. Maybe someone knows an extension command that would do it.<br><br>What happens if you !pte mydll+26474c?<br><br>It's certainly all a mystery. I don't do much user mode stuff though and I<br>don't use VS, so I might not be the best to comment on how prevalent this is<br>(first time I've seen it).<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>Yes this is the latest release. I know the PDB is loaded, but the !lmi<br>output says that the debug data is not mapped, which is what I meant. If I<br>connect to the process with Windbg from user-mode, it apparently maps it no<br>problem, which makes sense.<br><br>So this is probably an issue of the information being paged out/not mapped<br>and the kernel mode debugger not being able to get to it. Now I thought<br>specifying the image path would help this, since Windbg could just read the<br>debug data from the local image on disk.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 9:45 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No, it loaded symbols ("Symbol Type - PDB"). I assume this is the latest<br>release?<br><br>- S<br><br>-----Original Message-----<br>From: Jeff Curless <xxxxx><br>Sent: Monday, June 22, 2009 15:17<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: RE: Re:[windbg] Weird stack<br><br>Here is the info, looks like there is a problem due to debug data not being<br>mapped. Any idea how to fix that?<br><br>kd&gt; !lmi mydll.dll<br>Loaded Module Info: [mydll.dll]<br> Module: mydll<br> Base Address: 0000000180000000<br> Image Name: mydll.dll<br> Machine Type: 34404 (X64)<br> Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009<br> Size: 2da000<br> CheckSum: 0<br>Characteristics: 2022<br>Debug Data Dirs: Type Size VA Pointer<br> CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can't<br>validate symbols, if present.<br> Image Type: FILE - Image read successfully from debugger.<br> mydll.dll<br> Symbol Type: PDB - Symbols loaded successfully from symbol search<br>path.<br> e:\mydll\x64\debug\Mydll.pdb<br> Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]<br> Load Report: private symbols &amp; lines, not source indexed<br> e:\mydll\x64\debug\Mydll.pdb<br><br>kd&gt; !dh 0000000180000000<br><br>File Type: DLL<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 8 number of sections<br>4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 2022 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br> DLL<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br> 9.00 linker version<br> 1CAE00 size of code<br> 10AE00 size of initialized data<br> 0 size of uninitialized data<br> 10ECF0 address of entry point<br> 1000 base of code<br> ----- new -----<br>0000000180000000 image base<br> 1000 section alignment<br> 200 file alignment<br> 2 subsystem (Windows GUI)<br> 5.02 operating system version<br> 0.00 image version<br> 5.02 subsystem version<br> 2DA000 size of image<br> 400 size of headers<br> 0 checksum<br>0000000000100000 size of stack reserve<br>0000000000001000 size of stack commit<br>0000000000100000 size of heap reserve<br>0000000000001000 size of heap commit<br> 0 DLL characteristics<br> 295090 [173] address [size] of Export Directory<br> 2CE000 [3C] address [size] of Import Directory<br> 2D4000 [626] address [size] of Resource Directory<br> 2B3000 [179AC] address [size] of Exception Directory<br> 0 [0] address [size] of Security Directory<br> 2D5000 [2C08] address [size] of Base Relocation Directory<br> 1CD480 [1C] address [size] of Debug Directory<br> 0 [0] address [size] of Description Directory<br> 0 [0] address [size] of Special Directory<br> 0 [0] address [size] of Thread Storage Directory<br> 0 [0] address [size] of Load Configuration Directory<br> 0 [0] address [size] of Bound Import Directory<br> 2CE770 [730] address [size] of Import Address Table Directory<br> 2D0000 [1E0] address [size] of Delay Import Directory<br> 0 [0] address [size] of COR20 Header Directory<br> 0 [0] address [size] of Reserved Directory<br><br>I'm assuming that the address of the exception directory is a correct RVA<br>based off the image start so:<br><br>kd&gt; dq 0000001802b3000
00000001802b3000 ??????????? ???????????<br>00000001802b3010 ??????????? ???????????
00000001802b3020 ??????????? ???????????<br>00000001802b3030 ??????????? ???????????
00000001802b3040 ??????????? ???????????<br>00000001802b3050 ??????????? ???????????
00000001802b3060 ??????????? ???????????<br>00000001802b3070 ??????????? ???????????

Looks like it’s paged out.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 5:58 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes, that’s Bad™. That will cause stack tracing to behave incorrectly.
Do you have symbols loaded for mydll? (What’s !lmi mydll show?)

Can you read the exception directory (from !dh mydll – look for the
exception directory listing there to find its RVA and length) from mydll?

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No I don’t:

kd> .fnent mydll!myfunc
No function entry for 00000001800515f0<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Monday, June 22, 2009 4:53 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Weird stack<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>&gt;You should just use k instead of kv on amd64 as that is completely<br>&gt;unreadable.<br><br>It's important to have a really wide monitor when dealing with x64 dumps :)<br><br>I'm also entirely addicted to "kc" now, which shows a much more reasonable<br>call stack:<br><br>0: kd&gt; kc<br>Call Site<br>intelppm!C1Halt<br>intelppm!AcpiC1Idle<br>nt!PopProcessorIdle<br>nt!KiIdleLoop<br>nt!KiSystemStartup<br>0x0<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>&gt;Also if I do this:<br><br>&gt;Kd&gt; k<br>&gt;Child-SP RetAddr Call Site<br>&gt;000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]<br>&gt;000000000b29d698 0000000000000000 0x2a0f360<br><br>Very weird. If you do a<br><br>.fnent mydll!myfunction<br><br>Do you get a result?<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You should just use k instead of kv on amd64 as that is completely<br>unreadable. :( (Especially on a handheld screen!)<br><br>That being said, my guess is that you have an intervening frame for which<br>unwind information couldn't be pulled.<br><br>Unwinding on amd64 requires reading unwind metadata for each frame. This<br>can be problematic in kd because of things becoming paged out.<br><br>- If part of the loaded module list is paged out, or you did not load user<br>mode symbols beforehand, then the debugger won't have a binary for a given<br>frame's RIP and unwinding will break* because no unwind metadata can be<br>found.<br>- If symbols cannot be loaded and the unwind metadata for a binary is paged<br>out (not uncommon), then unwinding will break* because no unwind metadata<br>can be found.<br>- If you don't have symbol load notifications enabled (or otherwise weren't<br>there to get the notification at the time a particular binary was loaded),<br>and the image headers are paged out, then the debugger won't be able to get<br>unwind metadata and unwinding will break*.<br>- If the caller was JIT'd code, then unwinding will break* in kernel mode as<br>the kernel debugger doesn't support loading the JIT unwind helper DLL<br>(AFAIK).<br><br>*: I believe the debugger will treat these scenarios according to the<br>specification for a leaf function on amd64. This is going to be incorrect<br>for a function that isn't a leaf function.<br><br>In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your
first example), or mydll!myfunc3 000000000750d9e8 (your second example),<br>neither of which the debugger has associated with a loaded module. That<br>means the debugger probably gets lost at those respective frames because it<br>can't access the unwind table for those functions.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 12:56 PM<br>To: Kernel Debugging Interest List<br>Subject: RE:[windbg] Weird stack<br><br>Here is more. It appears to definitely be something to do with my PDBs as<br>the Microsoft ones from the symbol server look correct...<br><br># Child-SP RetAddr : Args to Child<br>: Call Site<br>00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78<br>000000000750d9d8 cccccccccccccccc : mydll!myfunc3<br>01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8<br>cccccccccccccccc 0000000007ab0d28 : 0x750d9e8<br>02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc<br>0000000007ab0d28 cccccc00cccccccc : 0x750d9e8<br>03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28<br>cccccc00cccccccc 00000001802b0268 : 0x750da78<br>04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc<br>00000001802b0268 cccccccccccccccc : 0x750d9d8<br>05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab0d28
07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc<br>08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe 000000000750d9e8 : mydll!myfunc2<br>09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc
0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8
000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc<br>0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8<br>cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc
0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000
cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe<br>0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x750d9e8<br>0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 000000000750dac0 : 0x750d9e8<br>0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>000000000750dac0 00000001800247f0 : 0xcccccccc00000000
10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0
00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc<br>11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0<br>0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc
12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60
000000000750da78 cccccccccccccccc : 0xcccccccccccccccc<br>13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78<br>cccccccccccccccc cccccccccccccccc : 0x750dac0<br>14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : mydll!myfunc1<br>15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 0000000007ab09a8 : 0xf6fd60<br>16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>0000000007ab09a8 cccccccccccccccc : 0x750da78<br>17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab09a8
1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc<br>1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc
1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc<br>cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc
1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc
0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc<br>20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680<br>000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe
21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f
0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc<br>22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760<br>0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc
23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827
00000000052f62b4 0000000000000400 : 0x7a99680
24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827
00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf
25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90
000007fefdb43a50 000007fefdb426d8 :
OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60
26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798
0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b
27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000
0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a
28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000
0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e
29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534
00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d
2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0
0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb
2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534
0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f
2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000
0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91
2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0
000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193
2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400
0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407
2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000
00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85
30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818
0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29
31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc
0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa
32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8
0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad
33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500
000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389
34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000
0000000000000000 0000000003440880 :
IEFRAME!CBrowserFrame::FrameMessagePump+0x411
35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801
00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d
36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98
37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df
38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

Thanks,
-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 3:47 PM
To: Kernel Debugging Interest List
Subject: [windbg] Weird stack

When I am kernel debugging on x64 and I am looking at a user-mode stack I
get a lot of funky output:

RetAddr : Args to Child
: Call Site
00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction2<br>00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction1
cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc
0000000000000000 : 0x2ad368<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccc`cccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Ken_Johnson]

You seem to be mapping the file as a data file and not as an image based on that code snippet (note that you passed FALSE to ImageDirectoryEntryToDataEx for MappedAsImage''). This means that you are working with file (physical’') offsets and not RVAs.

If you map the file as an image section (as the loader does), then RVA + ImageBase == absolute VA.

• S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, June 24, 2009 4:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Weird stack

The RVA is right - and yes, adding the RVA to the image base is all that’s
required.

Hmm…It’s been a while, but I wrote a test app for exploring this long ago
that I broke it out to verify before posting. It opens the file and memory
maps it as an EXE then dumps out the exception directory:

//
// Now get the exception directory from the image
//
exceptionTable = (PRUNTIME_FUNCTION)
ImageDirectoryEntryToDataEx(imageBase,
FALSE,
IMAGE_DIRECTORY_ENTRY_EXCEPTION,
&tableSize,
&sectionHeader);
Image base is 0x00390000:

0:000> !dh 0x00390000

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
4 number of sections
4A42B900 time date stamp Wed Jun 24 19:38:40 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

…

Exception directory is reportedly offset 0x5000:

0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

0:000> dc 0x00390000+5000
00395000 ??? ??? ??? ??? ???
00395010 ??? ??? ??? ??? ???

Exception table returned is 0x00392c00 :

0:000> dt exceptionTable
Local var @ 0x6ff60 Type _RUNTIME_FUNCTION*
0x00392c00
+0x000 BeginAddress : 0x1630
+0x004 EndAddress : 0x16b8
+0x008 UnwindData : 0x2ba0

If you step through ImageDirectoryEntryToDataEx you’ll end up in
ImageDirectoryEntryToData64 which does the calculation to return this
address.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
The RVA is right - and yes, adding the RVA to the image base is all that’s
required. The exception directory points to an array of RUNTIME_FUNCTION
structures which contain RVAs to the actual unwind info, which do not
necessarily need to reside within the exception directory.

In your case, the debugger seems to be using the fallback logic to
successfully pull this information from symbols data. This is what should
be happening for the OP.

I don’t know why this fallback isn’t working for the OP yet, unfortunately.
I haven’t repro’d this problem locally, but I’m only really looking at this
in my spare time either.

- S

-----Original Message-----
From: Scott Noone
Sent: Wednesday, June 24, 2009 08:20
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

>Now I thought specifying the image path would help this, since Windbg could
>just read the debug data from the local image on disk.

Image path is only there for minidumps, I don’t think that WinDBG uses it
for anything else.

>I’m assuming that the address of the exception directory is a correct RVA
>based off the image start so:

Not always. For example, I have an app loaded at 400000

0000000000400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.00 operating system version
6.00 image version
5.02 subsystem version
7000 size of image
400 size of headers
92BD checksum
…
0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

400000+5000 is bogus:

1: kd> dc 00400000+5000
0000000000405000 ???????? ???????? ???????? ???????? ????????????????<br>0000000000405010 ??? ??? ??? ??? ???

But the exception directory info is valid, just at a different address:

1: kd> .fnent canclapp!main
Debugger function entry 00000000007293f8 for:<br>c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)<br>(00000000004018e0) canclapp!main | (0000000000401c80)<br>canclapp!Reader<br>Exact matches:<br> canclapp!main (unsigned long, char **)<br><br>BeginAddress = 00000000000018e0
EndAddress = 0000000000001c76<br>UnwindInfoAddress = 0000000000002bb0

Unwind info at 0000000000402bb0, 10 bytes<br> version 1, flags 3, prolog 22, codes 2<br> frame reg 0, frame offs 0<br> handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178
00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188

(Note the "Unwind info at 0000000000402bb0")<br><br>It's easy to do the actual translation programmatically with<br>ImageDirectoryEntryToDataEx, though I don't know a quick way to do it in the<br>debugger. Maybe someone knows an extension command that would do it.<br><br>What happens if you !pte mydll+26474c?<br><br>It's certainly all a mystery. I don't do much user mode stuff though and I<br>don't use VS, so I might not be the best to comment on how prevalent this is<br>(first time I've seen it).<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>Yes this is the latest release. I know the PDB is loaded, but the !lmi<br>output says that the debug data is not mapped, which is what I meant. If I<br>connect to the process with Windbg from user-mode, it apparently maps it no<br>problem, which makes sense.<br><br>So this is probably an issue of the information being paged out/not mapped<br>and the kernel mode debugger not being able to get to it. Now I thought<br>specifying the image path would help this, since Windbg could just read the<br>debug data from the local image on disk.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 9:45 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No, it loaded symbols ("Symbol Type - PDB"). I assume this is the latest<br>release?<br><br>- S<br><br>-----Original Message-----<br>From: Jeff Curless <xxxxx><br>Sent: Monday, June 22, 2009 15:17<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: RE: Re:[windbg] Weird stack<br><br>Here is the info, looks like there is a problem due to debug data not being<br>mapped. Any idea how to fix that?<br><br>kd&gt; !lmi mydll.dll<br>Loaded Module Info: [mydll.dll]<br> Module: mydll<br> Base Address: 0000000180000000<br> Image Name: mydll.dll<br> Machine Type: 34404 (X64)<br> Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009<br> Size: 2da000<br> CheckSum: 0<br>Characteristics: 2022<br>Debug Data Dirs: Type Size VA Pointer<br> CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can't<br>validate symbols, if present.<br> Image Type: FILE - Image read successfully from debugger.<br> mydll.dll<br> Symbol Type: PDB - Symbols loaded successfully from symbol search<br>path.<br> e:\mydll\x64\debug\Mydll.pdb<br> Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]<br> Load Report: private symbols &amp; lines, not source indexed<br> e:\mydll\x64\debug\Mydll.pdb<br><br>kd&gt; !dh 0000000180000000<br><br>File Type: DLL<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 8 number of sections<br>4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 2022 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br> DLL<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br> 9.00 linker version<br> 1CAE00 size of code<br> 10AE00 size of initialized data<br> 0 size of uninitialized data<br> 10ECF0 address of entry point<br> 1000 base of code<br> ----- new -----<br>0000000180000000 image base<br> 1000 section alignment<br> 200 file alignment<br> 2 subsystem (Windows GUI)<br> 5.02 operating system version<br> 0.00 image version<br> 5.02 subsystem version<br> 2DA000 size of image<br> 400 size of headers<br> 0 checksum<br>0000000000100000 size of stack reserve<br>0000000000001000 size of stack commit<br>0000000000100000 size of heap reserve<br>0000000000001000 size of heap commit<br> 0 DLL characteristics<br> 295090 [173] address [size] of Export Directory<br> 2CE000 [3C] address [size] of Import Directory<br> 2D4000 [626] address [size] of Resource Directory<br> 2B3000 [179AC] address [size] of Exception Directory<br> 0 [0] address [size] of Security Directory<br> 2D5000 [2C08] address [size] of Base Relocation Directory<br> 1CD480 [1C] address [size] of Debug Directory<br> 0 [0] address [size] of Description Directory<br> 0 [0] address [size] of Special Directory<br> 0 [0] address [size] of Thread Storage Directory<br> 0 [0] address [size] of Load Configuration Directory<br> 0 [0] address [size] of Bound Import Directory<br> 2CE770 [730] address [size] of Import Address Table Directory<br> 2D0000 [1E0] address [size] of Delay Import Directory<br> 0 [0] address [size] of COR20 Header Directory<br> 0 [0] address [size] of Reserved Directory<br><br>I'm assuming that the address of the exception directory is a correct RVA<br>based off the image start so:<br><br>kd&gt; dq 0000001802b3000
00000001802b3000 ??????????? ???????????<br>00000001802b3010 ??????????? ???????????
00000001802b3020 ??????????? ???????????<br>00000001802b3030 ??????????? ???????????
00000001802b3040 ??????????? ???????????<br>00000001802b3050 ??????????? ???????????
00000001802b3060 ??????????? ???????????<br>00000001802b3070 ??????????? ???????????

Looks like it’s paged out.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 5:58 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes, that’s Bad™. That will cause stack tracing to behave incorrectly.
Do you have symbols loaded for mydll? (What’s !lmi mydll show?)

Can you read the exception directory (from !dh mydll – look for the
exception directory listing there to find its RVA and length) from mydll?

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No I don’t:

kd> .fnent mydll!myfunc
No function entry for 00000001800515f0<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Monday, June 22, 2009 4:53 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Weird stack<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>&gt;You should just use k instead of kv on amd64 as that is completely<br>&gt;unreadable.<br><br>It's important to have a really wide monitor when dealing with x64 dumps :)<br><br>I'm also entirely addicted to "kc" now, which shows a much more reasonable<br>call stack:<br><br>0: kd&gt; kc<br>Call Site<br>intelppm!C1Halt<br>intelppm!AcpiC1Idle<br>nt!PopProcessorIdle<br>nt!KiIdleLoop<br>nt!KiSystemStartup<br>0x0<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>&gt;Also if I do this:<br><br>&gt;Kd&gt; k<br>&gt;Child-SP RetAddr Call Site<br>&gt;000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]<br>&gt;000000000b29d698 0000000000000000 0x2a0f360<br><br>Very weird. If you do a<br><br>.fnent mydll!myfunction<br><br>Do you get a result?<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You should just use k instead of kv on amd64 as that is completely<br>unreadable. :( (Especially on a handheld screen!)<br><br>That being said, my guess is that you have an intervening frame for which<br>unwind information couldn't be pulled.<br><br>Unwinding on amd64 requires reading unwind metadata for each frame. This<br>can be problematic in kd because of things becoming paged out.<br><br>- If part of the loaded module list is paged out, or you did not load user<br>mode symbols beforehand, then the debugger won't have a binary for a given<br>frame's RIP and unwinding will break* because no unwind metadata can be<br>found.<br>- If symbols cannot be loaded and the unwind metadata for a binary is paged<br>out (not uncommon), then unwinding will break* because no unwind metadata<br>can be found.<br>- If you don't have symbol load notifications enabled (or otherwise weren't<br>there to get the notification at the time a particular binary was loaded),<br>and the image headers are paged out, then the debugger won't be able to get<br>unwind metadata and unwinding will break*.<br>- If the caller was JIT'd code, then unwinding will break* in kernel mode as<br>the kernel debugger doesn't support loading the JIT unwind helper DLL<br>(AFAIK).<br><br>*: I believe the debugger will treat these scenarios according to the<br>specification for a leaf function on amd64. This is going to be incorrect<br>for a function that isn't a leaf function.<br><br>In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your
first example), or mydll!myfunc3 000000000750d9e8 (your second example),<br>neither of which the debugger has associated with a loaded module. That<br>means the debugger probably gets lost at those respective frames because it<br>can't access the unwind table for those functions.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 12:56 PM<br>To: Kernel Debugging Interest List<br>Subject: RE:[windbg] Weird stack<br><br>Here is more. It appears to definitely be something to do with my PDBs as<br>the Microsoft ones from the symbol server look correct...<br><br># Child-SP RetAddr : Args to Child<br>: Call Site<br>00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78<br>000000000750d9d8 cccccccccccccccc : mydll!myfunc3<br>01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8<br>cccccccccccccccc 0000000007ab0d28 : 0x750d9e8<br>02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc<br>0000000007ab0d28 cccccc00cccccccc : 0x750d9e8<br>03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28<br>cccccc00cccccccc 00000001802b0268 : 0x750da78<br>04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc<br>00000001802b0268 cccccccccccccccc : 0x750d9d8<br>05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab0d28
07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc<br>08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe 000000000750d9e8 : mydll!myfunc2<br>09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc
0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8
000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc<br>0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8<br>cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc
0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000
cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe<br>0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x750d9e8<br>0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 000000000750dac0 : 0x750d9e8<br>0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>000000000750dac0 00000001800247f0 : 0xcccccccc00000000
10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0
00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc<br>11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0<br>0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc
12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60
000000000750da78 cccccccccccccccc : 0xcccccccccccccccc<br>13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78<br>cccccccccccccccc cccccccccccccccc : 0x750dac0<br>14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : mydll!myfunc1<br>15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 0000000007ab09a8 : 0xf6fd60<br>16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>0000000007ab09a8 cccccccccccccccc : 0x750da78<br>17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab09a8
1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc<br>1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc
1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc<br>cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc
1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc
0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc<br>20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680<br>000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe
21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f
0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc<br>22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760<br>0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc
23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827
00000000052f62b4 0000000000000400 : 0x7a99680
24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827
00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf
25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90
000007fefdb43a50 000007fefdb426d8 :
OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60
26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798
0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b
27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000
0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a
28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000
0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e
29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534
00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d
2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0
0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb
2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534
0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f
2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000
0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91
2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0
000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193
2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400
0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407
2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000
00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85
30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818
0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29
31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc
0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa
32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8
0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad
33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500
000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389
34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000
0000000000000000 0000000003440880 :
IEFRAME!CBrowserFrame::FrameMessagePump+0x411
35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801
00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d
36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98
37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df
38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

Thanks,
-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 3:47 PM
To: Kernel Debugging Interest List
Subject: [windbg] Weird stack

When I am kernel debugging on x64 and I am looking at a user-mode stack I
get a lot of funky output:

RetAddr : Args to Child
: Call Site
00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction2<br>00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction1
cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc
0000000000000000 : 0x2ad368<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccc`cccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Scott_Noone_OSR]

Oops, that’s what I get for trusting code I wrote three years ago on a
plane. It’s also another example of why I hate BOOLEAN inputs to functions,
makes it too easy to miss things like this.

Mapping it as an EXE returns the same unreadable address as we’ve seen
elsewhere. Strange, but clearly not Jeff’s problem.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You seem to be mapping the file as a data file and not as an image based on
that code snippet (note that you passed FALSE to ImageDirectoryEntryToDataEx
for MappedAsImage''). This means that you are working with file <br>(physical’') offsets and not RVAs.

If you map the file as an image section (as the loader does), then RVA +
ImageBase == absolute VA.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, June 24, 2009 4:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Re:Weird stack

>The RVA is right - and yes, adding the RVA to the image base is all that’s
>required.

Hmm…It’s been a while, but I wrote a test app for exploring this long ago
that I broke it out to verify before posting. It opens the file and memory
maps it as an EXE then dumps out the exception directory:

//
// Now get the exception directory from the image
//
exceptionTable = (PRUNTIME_FUNCTION)
ImageDirectoryEntryToDataEx(imageBase,
FALSE,
IMAGE_DIRECTORY_ENTRY_EXCEPTION,
&tableSize,
&sectionHeader);
Image base is 0x00390000:

0:000> !dh 0x00390000

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
4 number of sections
4A42B900 time date stamp Wed Jun 24 19:38:40 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

…

Exception directory is reportedly offset 0x5000:

0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

0:000> dc 0x00390000+5000
00395000 ??? ??? ??? ??? ???
00395010 ??? ??? ??? ??? ???

Exception table returned is 0x00392c00 :

0:000> dt exceptionTable
Local var @ 0x6ff60 Type _RUNTIME_FUNCTION*
0x00392c00
+0x000 BeginAddress : 0x1630
+0x004 EndAddress : 0x16b8
+0x008 UnwindData : 0x2ba0

If you step through ImageDirectoryEntryToDataEx you’ll end up in
ImageDirectoryEntryToData64 which does the calculation to return this
address.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
The RVA is right - and yes, adding the RVA to the image base is all that’s
required. The exception directory points to an array of RUNTIME_FUNCTION
structures which contain RVAs to the actual unwind info, which do not
necessarily need to reside within the exception directory.

In your case, the debugger seems to be using the fallback logic to
successfully pull this information from symbols data. This is what should
be happening for the OP.

I don’t know why this fallback isn’t working for the OP yet, unfortunately.
I haven’t repro’d this problem locally, but I’m only really looking at this
in my spare time either.

- S

-----Original Message-----
From: Scott Noone
Sent: Wednesday, June 24, 2009 08:20
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

>Now I thought specifying the image path would help this, since Windbg could
>just read the debug data from the local image on disk.

Image path is only there for minidumps, I don’t think that WinDBG uses it
for anything else.

>I’m assuming that the address of the exception directory is a correct RVA
>based off the image start so:

Not always. For example, I have an app loaded at 400000

0000000000400000 image base
1000 section alignment
200 file alignment
3 subsystem (Windows CUI)
6.00 operating system version
6.00 image version
5.02 subsystem version
7000 size of image
400 size of headers
92BD checksum
…
0 [0] address [size] of Export Directory
2BC0 [50] address [size] of Import Directory
0 [0] address [size] of Resource Directory
5000 [150] address [size] of Exception Directory

400000+5000 is bogus:

1: kd> dc 00400000+5000
0000000000405000 ???????? ???????? ???????? ???????? ????????????????<br>0000000000405010 ??? ??? ??? ??? ???

But the exception directory info is valid, just at a different address:

1: kd> .fnent canclapp!main
Debugger function entry 00000000007293f8 for:<br>c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)<br>(00000000004018e0) canclapp!main | (0000000000401c80)<br>canclapp!Reader<br>Exact matches:<br> canclapp!main (unsigned long, char **)<br><br>BeginAddress = 00000000000018e0
EndAddress = 0000000000001c76<br>UnwindInfoAddress = 0000000000002bb0

Unwind info at 0000000000402bb0, 10 bytes<br> version 1, flags 3, prolog 22, codes 2<br> frame reg 0, frame offs 0<br> handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178
00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188

(Note the "Unwind info at 0000000000402bb0")<br><br>It's easy to do the actual translation programmatically with<br>ImageDirectoryEntryToDataEx, though I don't know a quick way to do it in the<br>debugger. Maybe someone knows an extension command that would do it.<br><br>What happens if you !pte mydll+26474c?<br><br>It's certainly all a mystery. I don't do much user mode stuff though and I<br>don't use VS, so I might not be the best to comment on how prevalent this is<br>(first time I've seen it).<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>Yes this is the latest release. I know the PDB is loaded, but the !lmi<br>output says that the debug data is not mapped, which is what I meant. If I<br>connect to the process with Windbg from user-mode, it apparently maps it no<br>problem, which makes sense.<br><br>So this is probably an issue of the information being paged out/not mapped<br>and the kernel mode debugger not being able to get to it. Now I thought<br>specifying the image path would help this, since Windbg could just read the<br>debug data from the local image on disk.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 9:45 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No, it loaded symbols ("Symbol Type - PDB"). I assume this is the latest<br>release?<br><br>- S<br><br>-----Original Message-----<br>From: Jeff Curless <xxxxx><br>Sent: Monday, June 22, 2009 15:17<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: RE: Re:[windbg] Weird stack<br><br>Here is the info, looks like there is a problem due to debug data not being<br>mapped. Any idea how to fix that?<br><br>kd&gt; !lmi mydll.dll<br>Loaded Module Info: [mydll.dll]<br> Module: mydll<br> Base Address: 0000000180000000<br> Image Name: mydll.dll<br> Machine Type: 34404 (X64)<br> Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009<br> Size: 2da000<br> CheckSum: 0<br>Characteristics: 2022<br>Debug Data Dirs: Type Size VA Pointer<br> CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can't<br>validate symbols, if present.<br> Image Type: FILE - Image read successfully from debugger.<br> mydll.dll<br> Symbol Type: PDB - Symbols loaded successfully from symbol search<br>path.<br> e:\mydll\x64\debug\Mydll.pdb<br> Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]<br> Load Report: private symbols &amp; lines, not source indexed<br> e:\mydll\x64\debug\Mydll.pdb<br><br>kd&gt; !dh 0000000180000000<br><br>File Type: DLL<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 8 number of sections<br>4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 2022 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br> DLL<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br> 9.00 linker version<br> 1CAE00 size of code<br> 10AE00 size of initialized data<br> 0 size of uninitialized data<br> 10ECF0 address of entry point<br> 1000 base of code<br> ----- new -----<br>0000000180000000 image base<br> 1000 section alignment<br> 200 file alignment<br> 2 subsystem (Windows GUI)<br> 5.02 operating system version<br> 0.00 image version<br> 5.02 subsystem version<br> 2DA000 size of image<br> 400 size of headers<br> 0 checksum<br>0000000000100000 size of stack reserve<br>0000000000001000 size of stack commit<br>0000000000100000 size of heap reserve<br>0000000000001000 size of heap commit<br> 0 DLL characteristics<br> 295090 [173] address [size] of Export Directory<br> 2CE000 [3C] address [size] of Import Directory<br> 2D4000 [626] address [size] of Resource Directory<br> 2B3000 [179AC] address [size] of Exception Directory<br> 0 [0] address [size] of Security Directory<br> 2D5000 [2C08] address [size] of Base Relocation Directory<br> 1CD480 [1C] address [size] of Debug Directory<br> 0 [0] address [size] of Description Directory<br> 0 [0] address [size] of Special Directory<br> 0 [0] address [size] of Thread Storage Directory<br> 0 [0] address [size] of Load Configuration Directory<br> 0 [0] address [size] of Bound Import Directory<br> 2CE770 [730] address [size] of Import Address Table Directory<br> 2D0000 [1E0] address [size] of Delay Import Directory<br> 0 [0] address [size] of COR20 Header Directory<br> 0 [0] address [size] of Reserved Directory<br><br>I'm assuming that the address of the exception directory is a correct RVA<br>based off the image start so:<br><br>kd&gt; dq 0000001802b3000
00000001802b3000 ??????????? ???????????<br>00000001802b3010 ??????????? ???????????
00000001802b3020 ??????????? ???????????<br>00000001802b3030 ??????????? ???????????
00000001802b3040 ??????????? ???????????<br>00000001802b3050 ??????????? ???????????
00000001802b3060 ??????????? ???????????<br>00000001802b3070 ??????????? ???????????

Looks like it’s paged out.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 5:58 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Yes, that’s Bad™. That will cause stack tracing to behave incorrectly.
Do you have symbols loaded for mydll? (What’s !lmi mydll show?)

Can you read the exception directory (from !dh mydll – look for the
exception directory listing there to find its RVA and length) from mydll?

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 2:08 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No I don’t:

kd> .fnent mydll!myfunc
No function entry for 00000001800515f0<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Monday, June 22, 2009 4:53 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Weird stack<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>&gt;You should just use k instead of kv on amd64 as that is completely<br>&gt;unreadable.<br><br>It's important to have a really wide monitor when dealing with x64 dumps :)<br><br>I'm also entirely addicted to "kc" now, which shows a much more reasonable<br>call stack:<br><br>0: kd&gt; kc<br>Call Site<br>intelppm!C1Halt<br>intelppm!AcpiC1Idle<br>nt!PopProcessorIdle<br>nt!KiIdleLoop<br>nt!KiSystemStartup<br>0x0<br><br>"Jeff Curless" <xxxxx> wrote in message news:xxxxx@windbg...<br>&gt;Also if I do this:<br><br>&gt;Kd&gt; k<br>&gt;Child-SP RetAddr Call Site<br>&gt;000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]<br>&gt;000000000b29d698 0000000000000000 0x2a0f360<br><br>Very weird. If you do a<br><br>.fnent mydll!myfunction<br><br>Do you get a result?<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You should just use k instead of kv on amd64 as that is completely<br>unreadable. :( (Especially on a handheld screen!)<br><br>That being said, my guess is that you have an intervening frame for which<br>unwind information couldn't be pulled.<br><br>Unwinding on amd64 requires reading unwind metadata for each frame. This<br>can be problematic in kd because of things becoming paged out.<br><br>- If part of the loaded module list is paged out, or you did not load user<br>mode symbols beforehand, then the debugger won't have a binary for a given<br>frame's RIP and unwinding will break* because no unwind metadata can be<br>found.<br>- If symbols cannot be loaded and the unwind metadata for a binary is paged<br>out (not uncommon), then unwinding will break* because no unwind metadata<br>can be found.<br>- If you don't have symbol load notifications enabled (or otherwise weren't<br>there to get the notification at the time a particular binary was loaded),<br>and the image headers are paged out, then the debugger won't be able to get<br>unwind metadata and unwinding will break*.<br>- If the caller was JIT'd code, then unwinding will break* in kernel mode as<br>the kernel debugger doesn't support loading the JIT unwind helper DLL<br>(AFAIK).<br><br>*: I believe the debugger will treat these scenarios according to the<br>specification for a leaf function on amd64. This is going to be incorrect<br>for a function that isn't a leaf function.<br><br>In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your
first example), or mydll!myfunc3 000000000750d9e8 (your second example),<br>neither of which the debugger has associated with a loaded module. That<br>means the debugger probably gets lost at those respective frames because it<br>can't access the unwind table for those functions.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 12:56 PM<br>To: Kernel Debugging Interest List<br>Subject: RE:[windbg] Weird stack<br><br>Here is more. It appears to definitely be something to do with my PDBs as<br>the Microsoft ones from the symbol server look correct...<br><br># Child-SP RetAddr : Args to Child<br>: Call Site<br>00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78<br>000000000750d9d8 cccccccccccccccc : mydll!myfunc3<br>01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8<br>cccccccccccccccc 0000000007ab0d28 : 0x750d9e8<br>02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc<br>0000000007ab0d28 cccccc00cccccccc : 0x750d9e8<br>03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28<br>cccccc00cccccccc 00000001802b0268 : 0x750da78<br>04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc<br>00000001802b0268 cccccccccccccccc : 0x750d9d8<br>05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab0d28
07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc<br>08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe 000000000750d9e8 : mydll!myfunc2<br>09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc
0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8
000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc<br>0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8<br>cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc
0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000
cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe<br>0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x750d9e8<br>0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 000000000750dac0 : 0x750d9e8<br>0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>000000000750dac0 00000001800247f0 : 0xcccccccc00000000
10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0
00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc<br>11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0<br>0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc
12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60
000000000750da78 cccccccccccccccc : 0xcccccccccccccccc<br>13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78<br>cccccccccccccccc cccccccccccccccc : 0x750dac0<br>14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : mydll!myfunc1<br>15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc 0000000007ab09a8 : 0xf6fd60<br>16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>0000000007ab09a8 cccccccccccccccc : 0x750da78<br>17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x7ab09a8
1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc<br>1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc
1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc<br>cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc
1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc
0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc<br>20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680<br>000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe
21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f
0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc<br>22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760<br>0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc
23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827
00000000052f62b4 0000000000000400 : 0x7a99680
24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827
00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf
25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90
000007fefdb43a50 000007fefdb426d8 :
OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60
26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798
0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b
27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000
0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a
28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000
0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e
29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534
00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d
2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0
0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb
2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534
0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f
2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000
0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91
2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0
000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193
2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400
0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407
2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000
00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85
30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818
0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29
31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc
0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa
32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8
0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad
33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500
000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389
34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000
0000000000000000 0000000003440880 :
IEFRAME!CBrowserFrame::FrameMessagePump+0x411
35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801
00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d
36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98
37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df
38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

Thanks,
-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 3:47 PM
To: Kernel Debugging Interest List
Subject: [windbg] Weird stack

When I am kernel debugging on x64 and I am looking at a user-mode stack I
get a lot of funky output:

RetAddr : Args to Child
: Call Site
00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction2<br>00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction1
cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc
0000000000000000 : 0x2ad368<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccccccccccc<br>0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : 0xcccccccc`cccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Ken_Johnson]

I’m pretty sure that you’ve got something else going on specific to your test case. RVAs are always relative to the image base. Are you sure that you’re really mapping the file with SEC_IMAGE? Note that LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE does *not* do this.

Simple test here confirms:

(2644.1f74): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000`773e4ea0 cc int 3
0:001> !dh notepad

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
8664 machine (X64)
5 number of sections
47919766 time date stamp Fri Jan 18 22:23:34 2008

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
App can handle >2gb addresses

OPTIONAL HEADER VALUES
20B magic #

[…]

13000 [3CC] address [size] of Exception Directory

[…]

0:001> $ Let’s find the first runtime function out of the exception directory…
0:001> dt ntdll!_RUNTIME_FUNCTION notepad+13000
+0x000 BeginAddress : 0x4c9c
+0x004 EndAddress : 0x4cbd
+0x008 UnwindData : 0xdcd4
0:001> $ Verify that the debugger’s logic concurs with our calculations.
0:001> .fnent notepad+0x4c9c
Debugger function entry 00000000036e10d0 for: notepad!CFileDialogEvents_Release | (00000000ffde4cc4) notepad!CFileDialogEvents_OnFileOk
Exact matches:
notepad!CFileDialogEvents_Release

BeginAddress = 0000000000004c9c EndAddress = 0000000000004cbd
UnwindInfoAddress = 00000000`0000dcd4

Unwind info at 00000000ffdedcd4, 8 bytes version 1, flags 0, prolog 6, codes 2 frame reg 0, frame offs 0 00: offs 6, unwind op 2, op info 3 UWOP_ALLOC_SMALL 01: offs 2, unwind op 0, op info 3 UWOP_PUSH_NONVOL 0:001\> ? notepad+dcd4 Evaluate expression: 4292795604 = 00000000ffdedcd4
0:001> $ Verify that we really read data from the exception directory with dt, and that it makes sense given that data.
0:001> dc notepad+13000
00000000ffdf3000 00004c9c 00004cbd 0000dcd4 00004cd0 .L...L.......L.. 00000000ffdf3010 00004e5f 0000d96c 00004e68 00004ed6 _N…l…hN…N…
00000000ffdf3020 0000daa4 00004f3c 00004f9d 0000d960 ....<o...o..>00000000ffdf3030 00004fa4 00004ffd 0000d7f0 00005004 .O…O…P…
00000000ffdf3040 000050df 0000db60 000050e8 0000529c .P..…P…R…
00000000ffdf3050 0000da90 000052a4 000053c1 0000db60 .....R...S..…
00000000ffdf3060 000053c8 0000553d 0000dbe0 00005544 .S..=U......DU..<br>00000000ffdf3070 0000566c 0000db60 00005674 00005890 lV…...tV...X..<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Thursday, June 25, 2009 4:14 AM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Re:Re:Weird stack<br><br>Oops, that's what I get for trusting code I wrote three years ago on a<br>plane. It's also another example of why I hate BOOLEAN inputs to functions,<br>makes it too easy to miss things like this.<br><br>Mapping it as an EXE returns the same unreadable address as we've seen<br>elsewhere. Strange, but clearly not Jeff's problem.<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You seem to be mapping the file as a data file and not as an image based on<br>that code snippet (note that you passed FALSE to ImageDirectoryEntryToDataEx<br>for ``MappedAsImage''). This means that you are working with file<br>(``physical'') offsets and not RVAs.<br><br>If you map the file as an image section (as the loader does), then RVA +<br>ImageBase == absolute VA.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Wednesday, June 24, 2009 4:50 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Re:Weird stack<br><br>&gt;The RVA is right - and yes, adding the RVA to the image base is all that's<br>&gt;required.<br><br>Hmm...It's been a while, but I wrote a test app for exploring this long ago<br>that I broke it out to verify before posting. It opens the file and memory<br>maps it as an EXE then dumps out the exception directory:<br><br>//<br> // Now get the exception directory from the image<br> //<br> exceptionTable = (PRUNTIME_FUNCTION)<br> ImageDirectoryEntryToDataEx(imageBase,<br> FALSE,<br> IMAGE_DIRECTORY_ENTRY_EXCEPTION,<br> &amp;tableSize,<br> &amp;sectionHeader);<br>Image base is 0x00390000:<br><br>0:000&gt; !dh 0x00390000<br><br>File Type: EXECUTABLE IMAGE<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 4 number of sections<br>4A42B900 time date stamp Wed Jun 24 19:38:40 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 22 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br><br>...<br><br>Exception directory is reportedly offset 0x5000:<br><br>0 [0] address [size] of Export Directory<br> 2BC0 [50] address [size] of Import Directory<br> 0 [0] address [size] of Resource Directory<br> 5000 [150] address [size] of Exception Directory<br><br>0:000&gt; dc 0x00390000+5000<br>00395000 ???????? ???????? ???????? ???????? ????????????????<br>00395010 ???????? ???????? ???????? ???????? ????????????????<br><br>Exception table returned is 0x00392c00 :<br><br>0:000&gt; dt exceptionTable<br>Local var @ 0x6ff60 Type _RUNTIME_FUNCTION*<br>0x00392c00<br> +0x000 BeginAddress : 0x1630<br> +0x004 EndAddress : 0x16b8<br> +0x008 UnwindData : 0x2ba0<br><br>If you step through ImageDirectoryEntryToDataEx you'll end up in<br>ImageDirectoryEntryToData64 which does the calculation to return this<br>address.<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>The RVA is right - and yes, adding the RVA to the image base is all that's<br>required. The exception directory points to an array of RUNTIME_FUNCTION<br>structures which contain RVAs to the actual unwind info, which do not<br>necessarily need to reside within the exception directory.<br><br>In your case, the debugger seems to be using the fallback logic to<br>successfully pull this information from symbols data. This is what *should*<br>be happening for the OP.<br><br>I don't know why this fallback isn't working for the OP yet, unfortunately.<br>I haven't repro'd this problem locally, but I'm only really looking at this<br>in my spare time either.<br><br>- S<br><br>-----Original Message-----<br>From: Scott Noone <xxxxx><br>Sent: Wednesday, June 24, 2009 08:20<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: Re:[windbg] Weird stack<br><br>&gt;Now I thought specifying the image path would help this, since Windbg could<br>&gt;just read the debug data from the local image on disk.<br><br>Image path is only there for minidumps, I don't think that WinDBG uses it<br>for anything else.<br><br>&gt;I'm assuming that the address of the exception directory is a correct RVA<br>&gt;based off the image start so:<br><br>Not always. For example, I have an app loaded at 400000<br><br>0000000000400000 image base<br> 1000 section alignment<br> 200 file alignment<br> 3 subsystem (Windows CUI)<br> 6.00 operating system version<br> 6.00 image version<br> 5.02 subsystem version<br> 7000 size of image<br> 400 size of headers<br> 92BD checksum<br>...<br> 0 [0] address [size] of Export Directory<br> 2BC0 [50] address [size] of Import Directory<br> 0 [0] address [size] of Resource Directory<br> 5000 [150] address [size] of Exception Directory<br><br>400000+5000 is bogus:<br><br>1: kd&gt; dc 00400000+5000<br>0000000000405000 ??? ??? ??? ??? ???
0000000000405010 ???????? ???????? ???????? ???????? ????????????????<br><br>But the exception directory info is valid, just at a different address:<br><br>1: kd&gt; .fnent canclapp!main<br>Debugger function entry 00000000007293f8 for:
c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)
(00000000004018e0) canclapp!main | (0000000000401c80)
canclapp!Reader
Exact matches:
canclapp!main (unsigned long, char )

BeginAddress = 00000000000018e0<br>EndAddress = 0000000000001c76
UnwindInfoAddress = 0000000000002bb0<br><br>Unwind info at 0000000000402bb0, 10 bytes
version 1, flags 3, prolog 22, codes 2
frame reg 0, frame offs 0
handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178<br> 00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188<br><br>(Note the "Unwind info at 0000000000402bb0")

It’s easy to do the actual translation programmatically with
ImageDirectoryEntryToDataEx, though I don’t know a quick way to do it in the
debugger. Maybe someone knows an extension command that would do it.

What happens if you !pte mydll+26474c?

It’s certainly all a mystery. I don’t do much user mode stuff though and I
don’t use VS, so I might not be the best to comment on how prevalent this is
(first time I’ve seen it).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jeff Curless” wrote in message news:xxxxx@windbg…
Yes this is the latest release. I know the PDB is loaded, but the !lmi
output says that the debug data is not mapped, which is what I meant. If I
connect to the process with Windbg from user-mode, it apparently maps it no
problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped
and the kernel mode debugger not being able to get to it. Now I thought
specifying the image path would help this, since Windbg could just read the
debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest
release?

- S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being
mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t
validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search
path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA
based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly.<br>Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the<br>exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</o…o…>

[Scott_Noone_OSR]

Was also missing the SEC_IMAGE, if I specify that I get the same results as
you do (also see the same thing attaching to a local process on my x64
workstation).

This is what I get for writing a user mode app.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
I’m pretty sure that you’ve got something else going on specific to your
test case. RVAs are always relative to the image base. Are you sure that
you’re really mapping the file with SEC_IMAGE? Note that LoadLibraryEx with
LOAD_LIBRARY_AS_DATAFILE does not do this.

Simple test here confirms:

(2644.1f74): Break instruction exception - code 80000003 (first chance)
ntdll!DbgBreakPoint:
00000000773e4ea0 cc int 3<br>0:001&gt; !dh notepad<br><br>File Type: EXECUTABLE IMAGE<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 5 number of sections<br>47919766 time date stamp Fri Jan 18 22:23:34 2008<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 22 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br><br>[...]<br><br>13000 [3CC] address [size] of Exception Directory<br><br>[...]<br><br>0:001&gt; $ Let's find the first runtime function out of the exception <br>directory...<br>0:001&gt; dt ntdll!_RUNTIME_FUNCTION notepad+13000<br> +0x000 BeginAddress : 0x4c9c<br> +0x004 EndAddress : 0x4cbd<br> +0x008 UnwindData : 0xdcd4<br>0:001&gt; $ Verify that the debugger's logic concurs with our calculations.<br>0:001&gt; .fnent notepad+0x4c9c<br>Debugger function entry 00000000036e10d0 for:
notepad!CFileDialogEvents_Release | (00000000ffde4cc4) <br>notepad!CFileDialogEvents_OnFileOk<br>Exact matches:<br> notepad!CFileDialogEvents_Release<br><br>BeginAddress = 0000000000004c9c
EndAddress = 0000000000004cbd<br>UnwindInfoAddress = 000000000000dcd4

Unwind info at 00000000ffdedcd4, 8 bytes<br> version 1, flags 0, prolog 6, codes 2<br> frame reg 0, frame offs 0<br> 00: offs 6, unwind op 2, op info 3 UWOP_ALLOC_SMALL<br> 01: offs 2, unwind op 0, op info 3 UWOP_PUSH_NONVOL<br>0:001&gt; ? notepad+dcd4<br>Evaluate expression: 4292795604 = 00000000ffdedcd4
0:001> $ Verify that we really read data from the exception directory with
dt, and that it makes sense given that data.
0:001> dc notepad+13000
00000000ffdf3000 00004c9c 00004cbd 0000dcd4 00004cd0 .L...L.......L..<br>00000000ffdf3010 00004e5f 0000d96c 00004e68 00004ed6 _N…l…hN…N…
00000000ffdf3020 0000daa4 00004f3c 00004f9d 0000d960 ....<o...o..>00000000ffdf3030 00004fa4 00004ffd 0000d7f0 00005004 .O…O…P…
00000000ffdf3040 000050df 0000db60 000050e8 0000529c .P..…P…R…
00000000ffdf3050 0000da90 000052a4 000053c1 0000db60 .....R...S..…
00000000ffdf3060 000053c8 0000553d 0000dbe0 00005544 .S..=U......DU..<br>00000000ffdf3070 0000566c 0000db60 00005674 00005890 lV…...tV...X..<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com <br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Thursday, June 25, 2009 4:14 AM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Re:Re:Weird stack<br><br>Oops, that's what I get for trusting code I wrote three years ago on a<br>plane. It's also another example of why I hate BOOLEAN inputs to functions,<br>makes it too easy to miss things like this.<br><br>Mapping it as an EXE returns the same unreadable address as we've seen<br>elsewhere. Strange, but clearly not Jeff's problem.<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>You seem to be mapping the file as a data file and not as an image based on<br>that code snippet (note that you passed FALSE to ImageDirectoryEntryToDataEx<br>for ``MappedAsImage''). This means that you are working with file<br>(``physical'') offsets and not RVAs.<br><br>If you map the file as an image section (as the loader does), then RVA +<br>ImageBase == absolute VA.<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone<br>Sent: Wednesday, June 24, 2009 4:50 PM<br>To: Kernel Debugging Interest List<br>Subject: Re:[windbg] Re:Weird stack<br><br>&gt;The RVA is right - and yes, adding the RVA to the image base is all that's<br>&gt;required.<br><br>Hmm...It's been a while, but I wrote a test app for exploring this long ago<br>that I broke it out to verify before posting. It opens the file and memory<br>maps it as an EXE then dumps out the exception directory:<br><br>//<br> // Now get the exception directory from the image<br> //<br> exceptionTable = (PRUNTIME_FUNCTION)<br> ImageDirectoryEntryToDataEx(imageBase,<br> FALSE,<br> IMAGE_DIRECTORY_ENTRY_EXCEPTION,<br> &amp;tableSize,<br> &amp;sectionHeader);<br>Image base is 0x00390000:<br><br>0:000&gt; !dh 0x00390000<br><br>File Type: EXECUTABLE IMAGE<br>FILE HEADER VALUES<br> 8664 machine (X64)<br> 4 number of sections<br>4A42B900 time date stamp Wed Jun 24 19:38:40 2009<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 22 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br><br>...<br><br>Exception directory is reportedly offset 0x5000:<br><br>0 [0] address [size] of Export Directory<br> 2BC0 [50] address [size] of Import Directory<br> 0 [0] address [size] of Resource Directory<br> 5000 [150] address [size] of Exception Directory<br><br>0:000&gt; dc 0x00390000+5000<br>00395000 ???????? ???????? ???????? ???????? ????????????????<br>00395010 ???????? ???????? ???????? ???????? ????????????????<br><br>Exception table returned is 0x00392c00 :<br><br>0:000&gt; dt exceptionTable<br>Local var @ 0x6ff60 Type _RUNTIME_FUNCTION*<br>0x00392c00<br> +0x000 BeginAddress : 0x1630<br> +0x004 EndAddress : 0x16b8<br> +0x008 UnwindData : 0x2ba0<br><br>If you step through ImageDirectoryEntryToDataEx you'll end up in<br>ImageDirectoryEntryToData64 which does the calculation to return this<br>address.<br><br>-scott<br><br>--<br>Scott Noone<br>Consulting Associate<br>OSR Open Systems Resources, Inc.<br>http://www.osronline.com<br><br>"Skywing" <xxxxx> wrote in message<br>news:xxxxx@windbg...<br>The RVA is right - and yes, adding the RVA to the image base is all that's<br>required. The exception directory points to an array of RUNTIME_FUNCTION<br>structures which contain RVAs to the actual unwind info, which do not<br>necessarily need to reside within the exception directory.<br><br>In your case, the debugger seems to be using the fallback logic to<br>successfully pull this information from symbols data. This is what *should*<br>be happening for the OP.<br><br>I don't know why this fallback isn't working for the OP yet, unfortunately.<br>I haven't repro'd this problem locally, but I'm only really looking at this<br>in my spare time either.<br><br>- S<br><br>-----Original Message-----<br>From: Scott Noone <xxxxx><br>Sent: Wednesday, June 24, 2009 08:20<br>To: Kernel Debugging Interest List <xxxxx><br>Subject: Re:[windbg] Weird stack<br><br>&gt;Now I thought specifying the image path would help this, since Windbg could<br>&gt;just read the debug data from the local image on disk.<br><br>Image path is only there for minidumps, I don't think that WinDBG uses it<br>for anything else.<br><br>&gt;I'm assuming that the address of the exception directory is a correct RVA<br>&gt;based off the image start so:<br><br>Not always. For example, I have an app loaded at 400000<br><br>0000000000400000 image base<br> 1000 section alignment<br> 200 file alignment<br> 3 subsystem (Windows CUI)<br> 6.00 operating system version<br> 6.00 image version<br> 5.02 subsystem version<br> 7000 size of image<br> 400 size of headers<br> 92BD checksum<br>...<br> 0 [0] address [size] of Export Directory<br> 2BC0 [50] address [size] of Import Directory<br> 0 [0] address [size] of Resource Directory<br> 5000 [150] address [size] of Exception Directory<br><br>400000+5000 is bogus:<br><br>1: kd&gt; dc 00400000+5000<br>0000000000405000 ??? ??? ??? ??? ???
0000000000405010 ???????? ???????? ???????? ???????? ????????????????<br><br>But the exception directory info is valid, just at a different address:<br><br>1: kd&gt; .fnent canclapp!main<br>Debugger function entry 00000000007293f8 for:
c:\winddk\6001.18000\src\general\cancel\exe\testapp.c(69)
(00000000004018e0) canclapp!main | (0000000000401c80)
canclapp!Reader
Exact matches:
canclapp!main (unsigned long, char )

BeginAddress = 00000000000018e0<br>EndAddress = 0000000000001c76
UnwindInfoAddress = 0000000000002bb0<br><br>Unwind info at 0000000000402bb0, 10 bytes
version 1, flags 3, prolog 22, codes 2
frame reg 0, frame offs 0
handler routine: canclapp!__GSHandlerCheck (0000000000402644), data 178<br> 00: offs 10, unwind op 1, op info 0 UWOP_ALLOC_LARGE FrameOffset: 188<br><br>(Note the "Unwind info at 0000000000402bb0")

It’s easy to do the actual translation programmatically with
ImageDirectoryEntryToDataEx, though I don’t know a quick way to do it in the
debugger. Maybe someone knows an extension command that would do it.

What happens if you !pte mydll+26474c?

It’s certainly all a mystery. I don’t do much user mode stuff though and I
don’t use VS, so I might not be the best to comment on how prevalent this is
(first time I’ve seen it).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Jeff Curless” wrote in message news:xxxxx@windbg…
Yes this is the latest release. I know the PDB is loaded, but the !lmi
output says that the debug data is not mapped, which is what I meant. If I
connect to the process with Windbg from user-mode, it apparently maps it no
problem, which makes sense.

So this is probably an issue of the information being paged out/not mapped
and the kernel mode debugger not being able to get to it. Now I thought
specifying the image path would help this, since Windbg could just read the
debug data from the local image on disk.

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 22, 2009 9:45 PM
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

No, it loaded symbols (“Symbol Type - PDB”). I assume this is the latest
release?

- S

-----Original Message-----
From: Jeff Curless
Sent: Monday, June 22, 2009 15:17
To: Kernel Debugging Interest List
Subject: RE: Re:[windbg] Weird stack

Here is the info, looks like there is a problem due to debug data not being
mapped. Any idea how to fix that?

kd> !lmi mydll.dll
Loaded Module Info: [mydll.dll]
Module: mydll
Base Address: 0000000180000000
Image Name: mydll.dll
Machine Type: 34404 (X64)
Time Stamp: 4a3f57c8 Mon Jun 22 06:07:04 2009
Size: 2da000
CheckSum: 0
Characteristics: 2022
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 83, 26474c, 26394c [Debug data not mapped] - can’t
validate symbols, if present.
Image Type: FILE - Image read successfully from debugger.
mydll.dll
Symbol Type: PDB - Symbols loaded successfully from symbol search
path.
e:\mydll\x64\debug\Mydll.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
e:\mydll\x64\debug\Mydll.pdb

kd> !dh 0000000180000000

File Type: DLL
FILE HEADER VALUES
8664 machine (X64)
8 number of sections
4A3F57C8 time date stamp Mon Jun 22 06:07:04 2009

0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
App can handle >2gb addresses
DLL

OPTIONAL HEADER VALUES
20B magic #
9.00 linker version
1CAE00 size of code
10AE00 size of initialized data
0 size of uninitialized data
10ECF0 address of entry point
1000 base of code
----- new -----
0000000180000000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
5.02 operating system version
0.00 image version
5.02 subsystem version
2DA000 size of image
400 size of headers
0 checksum
0000000000100000 size of stack reserve
0000000000001000 size of stack commit
0000000000100000 size of heap reserve
0000000000001000 size of heap commit
0 DLL characteristics
295090 [173] address [size] of Export Directory
2CE000 [3C] address [size] of Import Directory
2D4000 [626] address [size] of Resource Directory
2B3000 [179AC] address [size] of Exception Directory
0 [0] address [size] of Security Directory
2D5000 [2C08] address [size] of Base Relocation Directory
1CD480 [1C] address [size] of Debug Directory
0 [0] address [size] of Description Directory
0 [0] address [size] of Special Directory
0 [0] address [size] of Thread Storage Directory
0 [0] address [size] of Load Configuration Directory
0 [0] address [size] of Bound Import Directory
2CE770 [730] address [size] of Import Address Table Directory
2D0000 [1E0] address [size] of Delay Import Directory
0 [0] address [size] of COR20 Header Directory
0 [0] address [size] of Reserved Directory

I’m assuming that the address of the exception directory is a correct RVA
based off the image start so:

kd> dq 0000001802b3000<br>00000001802b3000 ??????????? ???????????
00000001802b3010 ??????????? ???????????<br>00000001802b3020 ??????????? ???????????
00000001802b3030 ??????????? ???????????<br>00000001802b3040 ??????????? ???????????
00000001802b3050 ??????????? ???????????<br>00000001802b3060 ??????????? ???????????
00000001802b3070 ??????????? ???????????<br><br>Looks like it's paged out.<br><br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing<br>Sent: Monday, June 22, 2009 5:58 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>Yes, that's Bad(tm). That will cause stack tracing to behave incorrectly.<br>Do you have symbols loaded for mydll? (What's !lmi mydll show?)<br><br>Can you read the exception directory (from !dh mydll -- look for the<br>exception directory listing there to find its RVA and length) from mydll?<br><br>- S<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 2:08 PM<br>To: Kernel Debugging Interest List<br>Subject: RE: Re:[windbg] Weird stack<br><br>No I don't:<br><br>kd&gt; .fnent mydll!myfunc<br>No function entry for 00000001800515f0

-Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, June 22, 2009 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Weird stack

“Skywing” wrote in message
news:xxxxx@windbg…
>You should just use k instead of kv on amd64 as that is completely
>unreadable.

It’s important to have a really wide monitor when dealing with x64 dumps

I’m also entirely addicted to “kc” now, which shows a much more reasonable
call stack:

0: kd> kc
Call Site
intelppm!C1Halt
intelppm!AcpiC1Idle
nt!PopProcessorIdle
nt!KiIdleLoop
nt!KiSystemStartup
0x0

“Jeff Curless” wrote in message news:xxxxx@windbg…
>Also if I do this:

>Kd> k
>Child-SP RetAddr Call Site
>000000000b29d690 0000000002a0f360 mydll!myfunction+0x70 [my.cpp @ 128]
>000000000b29d698 0000000000000000 0x2a0f360

Very weird. If you do a

.fnent mydll!myfunction

Do you get a result?

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Skywing” wrote in message
news:xxxxx@windbg…
You should just use k instead of kv on amd64 as that is completely
unreadable. (Especially on a handheld screen!)

That being said, my guess is that you have an intervening frame for which
unwind information couldn’t be pulled.

Unwinding on amd64 requires reading unwind metadata for each frame. This
can be problematic in kd because of things becoming paged out.

- If part of the loaded module list is paged out, or you did not load user
mode symbols beforehand, then the debugger won’t have a binary for a given
frame’s RIP and unwinding will break because no unwind metadata can be
found.
- If symbols cannot be loaded and the unwind metadata for a binary is paged
out (not uncommon), then unwinding will break because no unwind metadata
can be found.
- If you don’t have symbol load notifications enabled (or otherwise weren’t
there to get the notification at the time a particular binary was loaded),
and the image headers are paged out, then the debugger won’t be able to get
unwind metadata and unwinding will break*.
- If the caller was JIT’d code, then unwinding will break* in kernel mode as
the kernel debugger doesn’t support loading the JIT unwind helper DLL
(AFAIK).

*: I believe the debugger will treat these scenarios according to the
specification for a leaf function on amd64. This is going to be incorrect
for a function that isn’t a leaf function.

In your case, we see mydll!myfunction1 returning to 00000000002ad368 (your<br>first example), or mydll!myfunc3 000000000750d9e8 (your second example),
neither of which the debugger has associated with a loaded module. That
means the debugger probably gets lost at those respective frames because it
can’t access the unwind table for those functions.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless
Sent: Monday, June 22, 2009 12:56 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Weird stack

Here is more. It appears to definitely be something to do with my PDBs as
the Microsoft ones from the symbol server look correct…

# Child-SP RetAddr : Args to Child
: Call Site
00 000000000750d9b0 000000000750d9e8 : 000000000750d9e8 000000000750da78
000000000750d9d8 cccccccccccccccc : mydll!myfunc3
01 000000000750d9b8 000000000750d9e8 : 000000000750da78 000000000750d9d8
cccccccccccccccc 0000000007ab0d28 : 0x750d9e8
02 000000000750d9c0 000000000750da78 : 000000000750d9d8 cccccccccccccccc
0000000007ab0d28 cccccc00cccccccc : 0x750d9e8
03 000000000750d9c8 000000000750d9d8 : cccccccccccccccc 0000000007ab0d28
cccccc00cccccccc 00000001802b0268 : 0x750da78
04 000000000750d9d0 cccccccccccccccc : 0000000007ab0d28 cccccc00cccccccc
00000001802b0268 cccccccccccccccc : 0x750d9d8
05 000000000750d9d8 0000000007ab0d28 : cccccc00cccccccc 00000001802b0268
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>06 000000000750d9e0 cccccc00cccccccc : 00000001802b0268 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab0d28<br>07 000000000750d9e8 00000001802b0268 : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccc00cccccccc
08 000000000750d9f0 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe 000000000750d9e8 : mydll!myfunc2
09 000000000750d9f8 cccccccccccccccc : cccccccccccccccc fffffffffffffffe
000000000750d9e8 000000000750d9e8 : 0xcccccccccccccccc<br>0a 000000000750da00 cccccccccccccccc : fffffffffffffffe 000000000750d9e8<br>000000000750d9e8 cccccccc00000000 : 0xcccccccccccccccc
0b 000000000750da08 fffffffffffffffe : 000000000750d9e8 000000000750d9e8
cccccccc00000000 cccccccccccccccc : 0xcccccccccccccccc<br>0c 000000000750da10 000000000750d9e8 : 000000000750d9e8 cccccccc00000000<br>cccccccccccccccc cccccccccccccccc : 0xfffffffffffffffe
0d 000000000750da18 000000000750d9e8 : cccccccc00000000 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0x750d9e8
0e 000000000750da20 cccccccc00000000 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 000000000750dac0 : 0x750d9e8
0f 000000000750da28 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
000000000750dac0 00000001800247f0 : 0xcccccccc00000000<br>10 000000000750da30 cccccccccccccccc : cccccccccccccccc 000000000750dac0<br>00000001800247f0 0000000000f6fd60 : 0xcccccccccccccccc
11 000000000750da38 cccccccccccccccc : 000000000750dac0 00000001800247f0
0000000000f6fd60 000000000750da78 : 0xcccccccccccccccc<br>12 000000000750da40 000000000750dac0 : 00000001800247f0 0000000000f6fd60<br>000000000750da78 cccccccccccccccc : 0xcccccccccccccccc
13 000000000750da48 00000001800247f0 : 0000000000f6fd60 000000000750da78
cccccccccccccccc cccccccccccccccc : 0x750dac0
14 000000000750da50 0000000000f6fd60 : 000000000750da78 cccccccccccccccc
cccccccccccccccc cccccccccccccccc : mydll!myfunc1
15 000000000750da58 000000000750da78 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc 0000000007ab09a8 : 0xf6fd60
16 000000000750da60 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
0000000007ab09a8 cccccccccccccccc : 0x750da78
17 000000000750da68 cccccccccccccccc : cccccccccccccccc 0000000007ab09a8
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>18 000000000750da70 cccccccccccccccc : 0000000007ab09a8 cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
19 000000000750da78 0000000007ab09a8 : cccccccccccccccc cccccccccccccccc
cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc<br>1a 000000000750da80 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc cccccccccccccccc : 0x7ab09a8<br>1b 000000000750da88 cccccccccccccccc : cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc fffffffffffffffe : 0xcccccccccccccccc
1c 000000000750da90 cccccccccccccccc : cccccccccccccccc cccccccccccccccc
fffffffffffffffe cccccccccccccccc : 0xcccccccccccccccc<br>1d 000000000750da98 cccccccccccccccc : cccccccccccccccc fffffffffffffffe<br>cccccccccccccccc cccccccccccccccc : 0xcccccccccccccccc
1e 000000000750daa0 cccccccccccccccc : fffffffffffffffe cccccccccccccccc
cccccccccccccccc 0000000007a99680 : 0xcccccccccccccccc<br>1f 000000000750daa8 fffffffffffffffe : cccccccccccccccc cccccccccccccccc<br>0000000007a99680 000007fefdaf528f : 0xcccccccccccccccc
20 000000000750dab0 cccccccccccccccc : cccccccccccccccc 0000000007a99680
000007fefdaf528f 0000000000f6b760 : 0xfffffffffffffffe<br>21 000000000750dab8 cccccccccccccccc : 0000000007a99680 000007fefdaf528f<br>0000000000f6b760 0000000005e9b827 : 0xcccccccccccccccc
22 000000000750dac0 0000000007a99680 : 000007fefdaf528f 0000000000f6b760
0000000005e9b827 00000000052f62b4 : 0xcccccccccccccccc<br>23 000000000750dac8 000007fefdaf528f : 0000000000f6b760 0000000005e9b827<br>00000000052f62b4 0000000000000400 : 0x7a99680<br>24 000000000750dad0 000007fefdaf54d0 : 000000000750df90 000007fe05e9b827<br>00000000052f62b4 000000000750de80 : OLEAUT32!IDispatch_Invoke_Stub+0xcf<br>25 000000000750db70 000007fefdbd599c : 000007fefdb40082 000000000750df90<br>000007fefdb43a50 000007fefdb426d8 :<br>OLEAUT32!IDispatch_RemoteInvoke_Thunk+0x60<br>26 000000000750dbe0 000007fefdc64442 : 0000000000000000 0000000007ab0798<br>0000000007a96200 000007fefdb625c0 : RPCRT4!NdrStubCall2+0xc0b<br>27 000000000750e1e0 000007fefdafb24e : 0000000000000001 0000000000000000<br>0000000007ab07a8 0000000007ab0770 : RPCRT4!CStdStubBuffer_Invoke+0x9a<br>28 000000000750e210 000007fefda18809 : 0000000000000000 0000000000000000<br>0000000000105f40 00000000001107a0 : OLEAUT32!CStubWrapper::Invoke+0x9e<br>29 000000000750e240 000007fefda1877f : 000000000010f8a0 0000000000117534<br>00000000001107a0 00000001801f7e48 : ole32!SyncStubInvoke+0x5d<br>2a 000000000750e2b0 000007fefd8e85ab : 000000000010f8a0 0000000005334ca0<br>0000000007a0d720 0000000000000001 : ole32!StubInvoke+0xdb<br>2b 000000000750e360 000007fefd8e9bf5 : cccccccc00000000 0000000000117534<br>0000000007ab0770 000000000010f8a0 : ole32!CCtxComChnl::ContextInvoke+0x19f<br>2c 000000000750e4e0 000007fefda18a83 : 0000000005334ca0 0000000000000000<br>0000000007a0d720 0000000000000000 : ole32!STAInvoke+0x91<br>2d 000000000750e530 000007fefda183b7 : 00000000d0908070 0000000005334ca0<br>000000000010fa30 00000000052f62b0 : ole32!AppInvoke+0x193<br>2e 000000000750e5a0 000007fefda18b15 : 000000000010f810 0000000000000400<br>0000000000000000 0000000000000000 : ole32!ComInvokeWithLockAndIPID+0x407<br>2f 000000000750e720 000007fefd8e9ad9 : 0000000000105f40 0000000000000000<br>00000000000ff008 000000000010f810 : ole32!ComInvoke+0x85<br>30 000000000750e750 000007fefd8e9982 : 0000000005334ca0 000000000010f818<br>0000000000000400 0000000000000000 : ole32!ThreadDispatch+0x29<br>31 000000000750e780 0000000076f5d24a : 0000000000000624 00000000000006cc<br>0000000000000000 0000000007a4fea0 : ole32!ThreadWndProc+0xaa<br>32 000000000750e800 0000000076f5d39e : 000000000750e980 000007fefd8e98d8<br>0000000000000000 0000000001068ae0 : USER32!UserCallWinProcCheckWow+0x1ad<br>33 000000000750e8c0 000007fef67e7a79 : 00000000052e9500 00000000052e9500<br>000007fefd8e98d8 0000000000000100 : USER32!DispatchMessageWorker+0x389<br>34 000000000750e940 000007fef68805ee : 00000000000f2a60 0000000000000000<br>0000000000000000 0000000003440880 :<br>IEFRAME!CBrowserFrame::FrameMessagePump+0x411<br>35 000000000750ea00 000007fef685bd65 : 0000000000000000 0000000000062801<br>00000000052e9500 0000000000000000 : IEFRAME!BrowserThreadProc+0x14d<br>36 000000000750eaa0 000007fef685bdcf : 1012733400000001 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!BrowserNewThreadProc+0x98<br>37 000000000750eae0 0000000076e3495d : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : IEFRAME!SHOpenFolderWindow+0x1df<br>38 000000000750fb90 0000000077038791 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd<br>39 000000000750fbc0 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d<br><br>Thanks,<br>-Jeff<br><br>-----Original Message-----<br>From: xxxxx@lists.osr.com<br>[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Curless<br>Sent: Monday, June 22, 2009 3:47 PM<br>To: Kernel Debugging Interest List<br>Subject: [windbg] Weird stack<br><br>When I am kernel debugging on x64 and I am looking at a user-mode stack I<br>get a lot of funky output:<br><br>RetAddr : Args to Child<br>: Call Site<br>00000001800247f0 : 00000000002ad368 cccccccccccccccc cccccccccccccccc<br>cccccccccccccccc : mydll!myfunction2
00000000002ad368 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : mydll!myfunction1<br>cccccccccccccccc : cccccccccccccccc cccccccccccccccc cccccccccccccccc<br>0000000000000000 : 0x2ad368
cccccccccccccccc : cccccccccccccccc cccccccccccccccc 0000000000000000
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : cccccccccccccccc 0000000000000000 cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
cccccccccccccccc : 0000000000000000 cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc
0000000000000000 : cccccccccccccccc cccccccccccccccc cccccccccccccccc
cccccccccccccccc : 0xcccccccccccccccc

This is a debug build of user-mode code, with matching PDBs. Has anyone
else seen this? It makes debugging a lot more of a pain to say the least…

Newest WinDbg, PDBs built with newest VS2008, newest service pack. VMWare
VM running Windows Vista x64, SP1.

Thanks!
-Jeff

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</o…o…>