I’m using textmode setup to install my xen drivers, and during setup of
Windows 2003 I’m getting a bug check:
0xD1 (0xxxxxxxxx, 0xFF, 0x8, 0xxxxxxxxx)
Based on what I can set from the debugprint output that I’m giving to
xen, the textmode setup completes, the system reboots, then later on
Windows is shutting down my bus driver (crash happens a few seconds
after EvtDeviceD0Exit(WdfPowerDeviceD3Final)) to reinstall it via the
.inf file on my driver disk. This is the first ever situation that I
have seen in which my bus driver unloads - normally it is in charge of
the boot device so unloading it is never an option, but I guess that
during setup it is entirely reasonable as there isn’t a boot drive yet.
I’m obviously leaving something running in the background that I haven’t
previously been aware of, and all the wdf safety checks aren’t picking
it up. Does an IRQL of 0xFF mean anything special, or just HIGH_LEVEL?
What windbg tricks could I use to find out what is going on?
I can’t access the machine right now, but I assume that putting the
correct magic commands in boot.ini will put the machine in debug mode
during the second phase of the install. Otherwise I’ll have to try and
engineer a situation where my driver can unload during normal use, which
is always dangerous as I’m changing the parameters of the crash.
Thanks
James
>
I’m using textmode setup to install my xen drivers, and during setup
of
Windows 2003 I’m getting a bug check:
0xD1 (0xxxxxxxxx, 0xFF, 0x8, 0xxxxxxxxx)
Based on what I can set from the debugprint output that I’m giving to
xen, the textmode setup completes, the system reboots, then later on
Windows is shutting down my bus driver (crash happens a few seconds
after EvtDeviceD0Exit(WdfPowerDeviceD3Final)) to reinstall it via the
.inf file on my driver disk. This is the first ever situation that I
have seen in which my bus driver unloads - normally it is in charge of
the boot device so unloading it is never an option, but I guess that
during setup it is entirely reasonable as there isn’t a boot drive
yet.
I’m obviously leaving something running in the background that I
haven’t
previously been aware of, and all the wdf safety checks aren’t picking
it up. Does an IRQL of 0xFF mean anything special, or just HIGH_LEVEL?
What windbg tricks could I use to find out what is going on?
I can’t access the machine right now, but I assume that putting the
correct magic commands in boot.ini will put the machine in debug mode
during the second phase of the install. Otherwise I’ll have to try and
engineer a situation where my driver can unload during normal use,
which
is always dangerous as I’m changing the parameters of the crash.
I found the error I think - I’d omitted the call to unhook DbgPrint (via
IDR under 2003), which also explains the odd IRQL (DbgPrint appears to
disable interrupts). Haven’t tested yet but I’m pretty sure that was it.
James