Comments on: WOW64 process, NULL data pointer, stack overflow, main thread, incorrect stack trace, nested exceptions, hidden exception, manual dump, multiple exceptions and virtualized system: pattern cooperation https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Wed, 06 May 2026 01:06:07 +0000 http://wordpress.org/?v=2.3.3 By: Crash Dump Analysis » Blog Archive » Old Mental Dumps from June 24th https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-160703 Crash Dump Analysis » Blog Archive » Old Mental Dumps from June 24th Thu, 24 Jun 2010 11:31:45 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-160703 [...] • Crash Dump Analysis Patterns (Part 67) - Nested Exception pattern. Appears also in the following case study: WOW64 process, NULL data pointer, stack overflow, main thread, incorrect stack trace, nested excepti... [...] […] • Crash Dump Analysis Patterns (Part 67) - Nested Exception pattern. Appears also in the following case study: WOW64 process, NULL data pointer, stack overflow, main thread, incorrect stack trace, nested excepti… […]

]]> By: Not a kernel guy https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84683 Not a kernel guy Tue, 14 Jul 2009 13:39:26 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84683 > Actually in parallel kernel dump forced after the crash in another thread context it shows the value of gs:0 > 1: kd> dq gs:0 > 002b:00000000`00000000 fffffa60`005fd280 fffffa60`005f6cc0 > 002b:00000000`00000010 00000000`0012fd48 fffffa60`005f3000 > 002b:00000000`00000020 fffffa60`005f3180 fffffa60`005f37f0 > 002b:00000000`00000030 000007ff`fffde000 fffffa60`005fd2f0 I'm a bit concerned about the kernel pointers here. In kernel mode the same gs is pointing to a kernel mode structure (PCR? I don't remember for sure), not to a TEB. It seems to be valid though. If you want to find out TEBs address use !teb. > I looked yesterday at Intel docs and I got the impression that they are still involved. cs, gs and fs are used. cs allows to select long or compatibility mode of execution. gs and fs allow to address TEBs but the CPU does not use the actual value loaded into gs/fs to locate the descriptor of the segment. It is established via some MSRs (I don't remeber which ones). ds, ss, es cannot be used in x64 code to address memory. You still can load a value to or from them but this values is not used in long mode. > Actually in parallel kernel dump forced after the crash in another thread context it shows the value of gs:0

> 1: kd> dq gs:0
> 002b:00000000`00000000 fffffa60`005fd280 fffffa60`005f6cc0
> 002b:00000000`00000010 00000000`0012fd48 fffffa60`005f3000
> 002b:00000000`00000020 fffffa60`005f3180 fffffa60`005f37f0
> 002b:00000000`00000030 000007ff`fffde000 fffffa60`005fd2f0

I’m a bit concerned about the kernel pointers here. In kernel mode the same gs is pointing to a kernel mode structure (PCR? I don’t remember for sure), not to a TEB. It seems to be valid though. If you want to find out TEBs address use !teb.

> I looked yesterday at Intel docs and I got the impression that they are still involved.

cs, gs and fs are used. cs allows to select long or compatibility mode of execution. gs and fs allow to address TEBs but the CPU does not use the actual value loaded into gs/fs to locate the descriptor of the segment. It is established via some MSRs (I don’t remeber which ones). ds, ss, es cannot be used in x64 code to address memory. You still can load a value to or from them but this values is not used in long mode.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84666 Dmitry Vostokov Tue, 14 Jul 2009 09:13:41 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84666 Here is exception record: <p align="left">0:000> .exr 00000000`0007e000+4d0 ExceptionAddress: 00000000750ca923 (wow64!Wow64SystemServiceEx+0x0000000000000057) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 0000000000000030 Attempt to read from address 0000000000000030</p> Actually in parallel kernel dump forced after the crash in another thread context it shows the value of gs:0 <p align="left">1: kd> dq gs:0 002b:00000000`00000000 fffffa60`005fd280 fffffa60`005f6cc0 002b:00000000`00000010 00000000`0012fd48 fffffa60`005f3000 002b:00000000`00000020 fffffa60`005f3180 fffffa60`005f37f0 002b:00000000`00000030 000007ff`fffde000 fffffa60`005fd2f0 002b:00000000`00000040 00000000`00000000 00000000`00000000 002b:00000000`00000050 00000000`00011800 00000000`00000000 002b:00000000`00000060 00000ad8`00010001 00000000`00000000 002b:00000000`00000070 00000000`00000000 00000000`00000000</p> Looks like selectors are still used to differentiate NULL pointers: <p align="left">1: kd> dq ds:0 002b:00000000`00000000 ????????`???????? ????????`???????? 002b:00000000`00000010 ????????`???????? ????????`???????? 002b:00000000`00000020 ????????`???????? ????????`???????? 002b:00000000`00000030 ????????`???????? ????????`???????? 002b:00000000`00000040 ????????`???????? ????????`???????? 002b:00000000`00000050 ????????`???????? ????????`???????? 002b:00000000`00000060 ????????`???????? ????????`???????? 002b:00000000`00000070 ????????`???????? ????????`????????</p> <p align="left">1: kd> dq ds:fffffa6006bf7558 002b:fffffa60`06bf7558 fffff800`0165712e 00000000`0000000a 002b:fffffa60`06bf7568 fffff880`058b1010 00000000`00000002 002b:fffffa60`06bf7578 00000000`00000000 fffffa60`053da17a 002b:fffffa60`06bf7588 00000000`00000000 00000000`00000000 002b:fffffa60`06bf7598 00000000`00000000 00000000`00000000 002b:fffffa60`06bf75a8 00000000`00000000 00000000`00000000 002b:fffffa60`06bf75b8 00000000`00000000 00000000`00000000 002b:fffffa60`06bf75c8 00000000`00000000 00000000`00000000</p> I looked yesterday at Intel docs and I got the impression that they are still involved. I try to find a reference in Intel docs later today and let you know. Perhaps I write another blog post about it :-) Here is exception record:

0:000> .exr 00000000`0007e000+4d0
ExceptionAddress: 00000000750ca923 (wow64!Wow64SystemServiceEx+0×0000000000000057)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000030
Attempt to read from address 0000000000000030

Actually in parallel kernel dump forced after the crash in another thread context it shows the value of gs:0

1: kd> dq gs:0
002b:00000000`00000000 fffffa60`005fd280 fffffa60`005f6cc0
002b:00000000`00000010 00000000`0012fd48 fffffa60`005f3000
002b:00000000`00000020 fffffa60`005f3180 fffffa60`005f37f0
002b:00000000`00000030 000007ff`fffde000 fffffa60`005fd2f0
002b:00000000`00000040 00000000`00000000 00000000`00000000
002b:00000000`00000050 00000000`00011800 00000000`00000000
002b:00000000`00000060 00000ad8`00010001 00000000`00000000
002b:00000000`00000070 00000000`00000000 00000000`00000000

Looks like selectors are still used to differentiate NULL pointers:

1: kd> dq ds:0
002b:00000000`00000000 ????????`???????? ????????`????????
002b:00000000`00000010 ????????`???????? ????????`????????
002b:00000000`00000020 ????????`???????? ????????`????????
002b:00000000`00000030 ????????`???????? ????????`????????
002b:00000000`00000040 ????????`???????? ????????`????????
002b:00000000`00000050 ????????`???????? ????????`????????
002b:00000000`00000060 ????????`???????? ????????`????????
002b:00000000`00000070 ????????`???????? ????????`????????

1: kd> dq ds:fffffa6006bf7558
002b:fffffa60`06bf7558 fffff800`0165712e 00000000`0000000a
002b:fffffa60`06bf7568 fffff880`058b1010 00000000`00000002
002b:fffffa60`06bf7578 00000000`00000000 fffffa60`053da17a
002b:fffffa60`06bf7588 00000000`00000000 00000000`00000000
002b:fffffa60`06bf7598 00000000`00000000 00000000`00000000
002b:fffffa60`06bf75a8 00000000`00000000 00000000`00000000
002b:fffffa60`06bf75b8 00000000`00000000 00000000`00000000
002b:fffffa60`06bf75c8 00000000`00000000 00000000`00000000

I looked yesterday at Intel docs and I got the impression that they are still involved. I try to find a reference in Intel docs later today and let you know. Perhaps I write another blog post about it :-)

]]> By: Not a kernel guy https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84656 Not a kernel guy Tue, 14 Jul 2009 05:38:07 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84656 > wow64!Wow64SystemServiceEx+0×57: > 00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h] It is just reading TEB. > gs:00000000`00000030=???????????????? There is a bug in the debugger that prevents it from showing memory adressed via a selector in x64 mode. It is bogus. > I see the function code makes 3 references to GS. Also we see that SS > and GS point to the same value 2B but we used SS implicitly before > that: Values of selectors are ignored in long (x64) mode. Selectors can be loaded with anything. It only matters in x86 code. What is the exception record? “.exr 00000000`0007e000+4d0” > wow64!Wow64SystemServiceEx+0×57:
> 00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h]

It is just reading TEB.

> gs:00000000`00000030=????????????????

There is a bug in the debugger that prevents it from showing memory adressed via a selector in x64 mode. It is bogus.

> I see the function code makes 3 references to GS. Also we see that SS
> and GS point to the same value 2B but we used SS implicitly before
> that:

Values of selectors are ignored in long (x64) mode. Selectors can be loaded with anything. It only matters in x86 code.

What is the exception record? “.exr 00000000`0007e000+4d0”

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84514 Dmitry Vostokov Mon, 13 Jul 2009 09:56:00 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84514 Thanks! It works: <p align="left">0:000> .cxr 00000000`0007e000 rax=0000000000000006 rbx=000000000017f29c rcx=000000000000100e rdx=000000000000000e rsi=000000000000c04c rdi=0000000000000000 rip=00000000750ca923 rsp=000000000007e5a0 rbp=000000000017f2a8 r8=0000000000000001 r9=00000000750ffd40 r10=0000000000000000 r11=000000000017f29c r12=000000007efdb000 r13=000000000007fd20 r14=000000000007ee70 r15=00000000751e3380 iopl=0 nv up ei ng nz na pe cy cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010283 wow64!Wow64SystemServiceEx+0x57: 00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h] gs:00000000`00000030=????????????????</font> <p align="left">0:000> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site 00000000`0007e5a0 00000000`751e3688 wow64!Wow64SystemServiceEx+0x57 00000000`0007ee50 00000000`750cab46 wow64cpu!ServiceNoTurbo+0x28 00000000`0007eee0 00000000`750ca14c wow64!RunCpuSimulation+0xa 00000000`0007ef10 00000000`771b52d3 wow64!Wow64LdrpInitialize+0x4b4 00000000`0007f470 00000000`771b5363 ntdll!LdrpInitializeProcess+0x14ac 00000000`0007f720 00000000`771a85ce ntdll! ?? ::FNODOBFM::`string'+0x1ff19 00000000`0007f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe</font> I see the function code makes 3 references to GS. Also we see that SS and GS point to the same value 2B but we used SS implicitly before that: <p align="left">0:000> uf wow64!Wow64SystemServiceEx wow64!Wow64SystemServiceEx: 00000000`750ca8cc 48895c2418 mov qword ptr [rsp+18h],rbx 00000000`750ca8d1 4889742420 mov qword ptr [rsp+20h],rsi 00000000`750ca8d6 57 push rdi 00000000`750ca8d7 4154 push r12 00000000`750ca8d9 4155 push r13 00000000`750ca8db 4881ec90080000 sub rsp,890h 00000000`750ca8e2 488b0517580200 mov rax,qword ptr [wow64!_security_cookie (00000000`750f0100)] 00000000`750ca8e9 4833c4 xor rax,rsp 00000000`750ca8ec 4889842480080000 mov qword ptr [rsp+880h],rax 00000000`750ca8f4 488bda mov rbx,rdx 00000000`750ca8f7 8bd1 mov edx,ecx 00000000`750ca8f9 448bc1 mov r8d,ecx 00000000`750ca8fc 41c1e80c shr r8d,0Ch 00000000`750ca900 4183e003 and r8d,3 00000000`750ca904 81e2ff0f0000 and edx,0FFFh 00000000`750ca90a 4b8d0440 lea rax,[r8+r8*2] 00000000`750ca90e 4803c0 add rax,rax 00000000`750ca911 4c8d0d28540300 lea r9,[wow64!ServiceTables (00000000`750ffd40)] 00000000`750ca918 413b54c110 cmp edx,dword ptr [r9+rax*8+10h] 00000000`750ca91d 0f8710010000 ja wow64!Wow64SystemServiceEx+0x167 (00000000`750caa33)</font> <p align="left">wow64!Wow64SystemServiceEx+0x57: 00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h]</font> So it must have been a H/W error or a virtualization error. I cannot send you the original dump but I try to model this issue on my PC and let you know. Thanks, Dmitry Thanks! It works:

0:000> .cxr 00000000`0007e000
rax=0000000000000006 rbx=000000000017f29c rcx=000000000000100e
rdx=000000000000000e rsi=000000000000c04c rdi=0000000000000000
rip=00000000750ca923 rsp=000000000007e5a0 rbp=000000000017f2a8
r8=0000000000000001 r9=00000000750ffd40 r10=0000000000000000
r11=000000000017f29c r12=000000007efdb000 r13=000000000007fd20
r14=000000000007ee70 r15=00000000751e3380
iopl=0 nv up ei ng nz na pe cy
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010283
wow64!Wow64SystemServiceEx+0×57:
00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h] gs:00000000`00000030=????????????????

0:000> k
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr Call Site
00000000`0007e5a0 00000000`751e3688 wow64!Wow64SystemServiceEx+0×57
00000000`0007ee50 00000000`750cab46 wow64cpu!ServiceNoTurbo+0×28
00000000`0007eee0 00000000`750ca14c wow64!RunCpuSimulation+0xa
00000000`0007ef10 00000000`771b52d3 wow64!Wow64LdrpInitialize+0×4b4
00000000`0007f470 00000000`771b5363 ntdll!LdrpInitializeProcess+0×14ac
00000000`0007f720 00000000`771a85ce ntdll! ?? ::FNODOBFM::`string’+0×1ff19
00000000`0007f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

I see the function code makes 3 references to GS. Also we see that SS and GS point to the same value 2B but we used SS implicitly before that:

0:000> uf wow64!Wow64SystemServiceEx
wow64!Wow64SystemServiceEx:
00000000`750ca8cc 48895c2418 mov qword ptr [rsp+18h],rbx
00000000`750ca8d1 4889742420 mov qword ptr [rsp+20h],rsi
00000000`750ca8d6 57 push rdi
00000000`750ca8d7 4154 push r12
00000000`750ca8d9 4155 push r13
00000000`750ca8db 4881ec90080000 sub rsp,890h
00000000`750ca8e2 488b0517580200 mov rax,qword ptr [wow64!_security_cookie (00000000`750f0100)]
00000000`750ca8e9 4833c4 xor rax,rsp
00000000`750ca8ec 4889842480080000 mov qword ptr [rsp+880h],rax
00000000`750ca8f4 488bda mov rbx,rdx
00000000`750ca8f7 8bd1 mov edx,ecx
00000000`750ca8f9 448bc1 mov r8d,ecx
00000000`750ca8fc 41c1e80c shr r8d,0Ch
00000000`750ca900 4183e003 and r8d,3
00000000`750ca904 81e2ff0f0000 and edx,0FFFh
00000000`750ca90a 4b8d0440 lea rax,[r8+r8*2]
00000000`750ca90e 4803c0 add rax,rax
00000000`750ca911 4c8d0d28540300 lea r9,[wow64!ServiceTables (00000000`750ffd40)]
00000000`750ca918 413b54c110 cmp edx,dword ptr [r9+rax*8+10h]
00000000`750ca91d 0f8710010000 ja wow64!Wow64SystemServiceEx+0×167 (00000000`750caa33)

wow64!Wow64SystemServiceEx+0×57:
00000000`750ca923 65488b3c2530000000 mov rdi,qword ptr gs:[30h]

So it must have been a H/W error or a virtualization error. I cannot send you the original dump but I try to model this issue on my PC and let you know.

Thanks,
Dmitry

]]> By: Not a kernel guy https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84371 Not a kernel guy Sun, 12 Jul 2009 19:01:45 +0000 https://www.dumpanalysis.org/blog/index.php/2009/07/12/wow64-process-null-data-pointer-stack-overflow-main-thread-incorrect-stack-trace-nested-exceptions-hidden-exception-manual-dump-multiple-exceptions-and-virtualized-system-pattern-cooperation/#comment-84371 <p align="left">> 00000000`0007dff8 00000000`771c59e6 ntdll!KiUserExceptionDispatcher+0×1c 00000000`0007e000 01c9f89c`fe787c8d 00000000`0007e008 fffffa60`03732e4e 00000000`0007e010 fffffa80`0497c9a0</font> x64 version of ntdll!KiUserExceptionDispatcher does not use EXCEPTION_POINTERS like its x86 counterpart. These pointers are just garbage. Use ".cxr 00000000`0007e000" and ".exr 00000000`0007e000+sizeof(CONTEXT)" to see the context and exception record. BTW: Can I get a copy of the dump to take a look? > 00000000`0007dff8 00000000`771c59e6 ntdll!KiUserExceptionDispatcher+0×1c
00000000`0007e000 01c9f89c`fe787c8d
00000000`0007e008 fffffa60`03732e4e
00000000`0007e010 fffffa80`0497c9a0

x64 version of ntdll!KiUserExceptionDispatcher does not use EXCEPTION_POINTERS like its x86 counterpart. These pointers are just garbage. Use “.cxr 00000000`0007e000″ and “.exr 00000000`0007e000+sizeof(CONTEXT)” to see the context and exception record.

BTW: Can I get a copy of the dump to take a look?

]]>