RE: VIRIDIAN CRASH: 3b c0000096 75b12c5 9e7f1580 0

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 03 February 2021 15:43
> To: paul@xxxxxxx
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; 'James Dingwall' 
> <james-xen@xxxxxxxxxxxxxx>
> Subject: Re: VIRIDIAN CRASH: 3b c0000096 75b12c5 9e7f1580 0
> 
> On 03.02.2021 16:04, Paul Durrant wrote:
> >> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan 
> >> Beulich
> >> Sent: 03 February 2021 14:55
> >>
> >> On 01.02.2021 16:26, James Dingwall wrote:
> >>> 21244@1612191983.282480:xen_platform_log xen platform: XEN|BUGCHECK: 
> >>> EXCEPTION (0000A824848948C2):
> >>> 21244@1612191983.282617:xen_platform_log xen platform: XEN|BUGCHECK: 
> >>> CONTEXT (FFFFD0014343D580):
> >>> 21244@1612191983.282717:xen_platform_log xen platform: XEN|BUGCHECK: - GS 
> >>> = 002B
> >>> 21244@1612191983.282816:xen_platform_log xen platform: XEN|BUGCHECK: - FS 
> >>> = 0053
> >>> 21244@1612191983.282914:xen_platform_log xen platform: XEN|BUGCHECK: - ES 
> >>> = 002B
> >>> 21244@1612191983.283011:xen_platform_log xen platform: XEN|BUGCHECK: - DS 
> >>> = 002B
> >>> 21244@1612191983.283127:xen_platform_log xen platform: XEN|BUGCHECK: - SS 
> >>> = 0018
> >>> 21244@1612191983.283226:xen_platform_log xen platform: XEN|BUGCHECK: - CS 
> >>> = 0010
> >>> 21244@1612191983.283332:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> EFLAGS = 00000202
> >>> 21244@1612191983.283444:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RDI = 00000000F64D5C20
> >>> 21244@1612191983.283555:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RSI = 00000000F6367280
> >>> 21244@1612191983.283666:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RBX = 000000008011E060
> >>> 21244@1612191983.283810:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RDX = 00000000F64D5C20
> >>> 21244@1612191983.283972:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RCX = 0000000000000199
> >>> 21244@1612191983.284350:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RAX = 0000000000000004
> >>> 21244@1612191983.284523:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RBP = 000000004343E891
> >>> 21244@1612191983.284658:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RIP = 00000000A43C72C5
> >>> 21244@1612191983.284842:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> RSP = 000000004343DFA0
> >>> 21244@1612191983.284959:xen_platform_log xen platform: XEN|BUGCHECK: - R8 
> >>> = 0000000000000008
> >>> 21244@1612191983.285073:xen_platform_log xen platform: XEN|BUGCHECK: - R9 
> >>> = 000000000000000E
> >>> 21244@1612191983.285188:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R10 = 0000000000000002
> >>> 21244@1612191983.285304:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R11 = 000000004343E808
> >>> 21244@1612191983.285420:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R12 = 0000000000000000
> >>> 21244@1612191983.285564:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R13 = 00000000F7964E50
> >>> 21244@1612191983.285680:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R14 = 00000000F64D5C20
> >>> 21244@1612191983.285796:xen_platform_log xen platform: XEN|BUGCHECK: - 
> >>> R15 = 00000000F7964E50
> >>
> >> I'm also confused by this - the pointer given for CONTEXT suggests this
> >> is a 64-bit kernel, yet none of the registers - including RIP and RSP -
> >> have non-zero upper 32 bits. Or is qemu truncating these values?
> >
> > The logging is coming from the PV drivers (in
> https://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenbus.git;a=blob;f=src/xen/bug_check.c).
>  The
> truncated values may just be due to a 32-bit user process I guess.
> 
> Since you pointed me at the code and truncation inside a string
> not likely being due to some user process, I went and looked:
> The driver uses %016X, instead of e.g. converting to (PVOID)
> and using %p like code elsewhere in the file does (presumably
> because there's no really convenient way to print 64-bit values
> in Windows, short of using their custom "%016I64X" format
> specifier, and the absence of a uniform specifier allowing to
> format pointer-sized integers independent of architecture).

Oh yes, good point... Other places in the code use the %p trick. It should be 
changed.

  Paul

> 
> Jan