This problem is still happening. I’m now pretty sure that the problem
lies somewhere in Xen, but I want to know if my interpretation of this
bug check is correct:
BUGCHECK_STR: 0x7f_d
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: msdtc.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 816a3bd8 to 816a74f7
STACK_TEXT:
9724ad68 816a3bd8 badb0d00 77a29a94 00000000
nt!KiSystemFatalException+0xf
0098fb50 01467230 00000064 00000000 0098fb9c nt!KiSystemCallExit2+0x18
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0098fbf0 00000000 72be198e 01467230 ffffffff 0x1467230
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiSystemFatalException+f816a74f7 c3 ret
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KiSystemFatalException+f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
FAILURE_BUCKET_ID: 0x7f_d_VRF_nt!KiSystemFatalException+f
BUCKET_ID: 0x7f_d_VRF_nt!KiSystemFatalException+f
All my crashes are pretty much identical to this, with the exception
that the PROCESS_NAME is different each time.
The top two calls on the stack are always the same, and it appears to me
that KiSystemCallExit is trying to return to usermode but finding
usermode broken in some fundamental way (corrupt stack?) and causing a
crash.
This is happening every time xen restores my VM from a saved state, so
I’m now thinking that Xen is mangling something up, but I can’t imagine
what at this stage (I’ve never looked at the save/restore code).
Can anyone give me any hints as to what might cause this?
Thanks
James
Just for the archives, the problem turned out to be a bug in Xen (the
price of using pre-RC code I guess
on my particular AMD CPU. The
syscall MSR’s weren’t being saved/restored during migration which
resulted in this particular explosion on return to userspace.
James
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-438648-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Tuesday, 25 January 2011 14:12
To: Windows System Software Devs Interest List
Subject: [ntdev] bug check 0x7f (0xd, 0, 0, 0)
This problem is still happening. I’m now pretty sure that the problem
lies somewhere in Xen, but I want to know if my interpretation of this
bug check is correct:
BUGCHECK_STR: 0x7f_d
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: msdtc.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 816a3bd8 to 816a74f7
STACK_TEXT:
9724ad68 816a3bd8 badb0d00 77a29a94 00000000
nt!KiSystemFatalException+0xf
0098fb50 01467230 00000064 00000000 0098fb9c nt!KiSystemCallExit2+0x18
WARNING: Frame IP not in any known module. Following frames may be
wrong.
0098fbf0 00000000 72be198e 01467230 ffffffff 0x1467230
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiSystemFatalException+f816a74f7 c3 ret
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!KiSystemFatalException+f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
FAILURE_BUCKET_ID: 0x7f_d_VRF_nt!KiSystemFatalException+f
BUCKET_ID: 0x7f_d_VRF_nt!KiSystemFatalException+f
All my crashes are pretty much identical to this, with the exception
that the PROCESS_NAME is different each time.
The top two calls on the stack are always the same, and it appears to
me
that KiSystemCallExit is trying to return to usermode but finding
usermode broken in some fundamental way (corrupt stack?) and causing a
crash.
This is happening every time xen restores my VM from a saved state, so
I’m now thinking that Xen is mangling something up, but I can’t
imagine
what at this stage (I’ve never looked at the save/restore code).
Can anyone give me any hints as to what might cause this?
Thanks
James
NTDEV 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