Xen devel - Oct 2009 - bug in windows "on_reboot = ''preserve''"

Prior to 3.4.x (I think), when I said "on_reboot =
''preserve''" in the
config, vnc would show me a windows BSOD just fine. For 3.4.1, I just
get a garbed screen.

Any suggestions as to what changed?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Different qemu version with Xen changes forward-ported onto it. You can
imagine various corner cases may have changed w.r.t. things like video
emulation.

 -- Keir

On 25/10/2009 07:57, "James Harper"
<james.harper@bendigoit.com.au> wrote:
> Prior to 3.4.x (I think), when I said "on_reboot =
''preserve''" in the
> config, vnc would show me a windows BSOD just fine. For 3.4.1, I just
> get a garbed screen.
> 
> Any suggestions as to what changed?
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

James Harper writes ("[Xen-devel] bug in windows "on_reboot =
''preserve''""):
> Prior to 3.4.x (I think), when I said "on_reboot =
''preserve''" in the
> config, vnc would show me a windows BSOD just fine. For 3.4.1, I just
> get a garbed screen.
> 
> Any suggestions as to what changed?
As Keir says, 3.4''s qemu-dm is based on a substantially later upstream
version of qemu.  However the video code is much less significantly
changed and it might actually be possible to debug it.

I''ll see if I can reproduce the problem.  How do I get my Windows
guest to BSOD ? :-)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> James Harper writes ("[Xen-devel] bug in windows "on_reboot
''preserve''""):
> > Prior to 3.4.x (I think), when I said "on_reboot =
''preserve''" in
the
> > config, vnc would show me a windows BSOD just fine. For 3.4.1, I
just
> > get a garbed screen.
> >
> > Any suggestions as to what changed?
> 
> As Keir says, 3.4''s qemu-dm is based on a substantially later
upstream
> version of qemu.  However the video code is much less significantly
> changed and it might actually be possible to debug it.
> 
> I''ll see if I can reproduce the problem.  How do I get my Windows
> guest to BSOD ? :-)
> 
With GPLPV, I added a sysrq handler such that ''B'' causes an
immediate
bug check. If you have a windows system that you are happy to destroy,
something like deleting a critical driver might do the trick, unless
Windows detects it and puts it back again. Deleting a critical
HKLM\SYSTEM\CurrentControlSet\Services\xxx service key might also work -
if you delete the key for a boot time driver you''ll get an 0x7B bug
check.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

At 16:51 +0000 on 28 Oct (1256748714), Ian Jackson
wrote:
> James Harper writes ("[Xen-devel] bug in windows "on_reboot =
''preserve''""):
> > Prior to 3.4.x (I think), when I said "on_reboot =
''preserve''" in the
> > config, vnc would show me a windows BSOD just fine. For 3.4.1, I just
> > get a garbed screen.
> > 
> > Any suggestions as to what changed?
> 
> As Keir says, 3.4''s qemu-dm is based on a substantially later
upstream
> version of qemu.  However the video code is much less significantly
> changed and it might actually be possible to debug it.
> 
> I''ll see if I can reproduce the problem.  How do I get my Windows
> guest to BSOD ? :-)
http://support.microsoft.com/kb/969028 gives many entertaining ways,
but the NotMyFault tool is proabably easiest.  Download it from
http://download.sysinternals.com/Files/Notmyfault.zip and run
"NotMyFault.exe /crash".

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Following is a way to make system crash from keyboard.

Thanks
Annie.


  Forcing a System Crash from the Keyboard

A system crash can be directly caused from most keyboards. In 
Windows XP, this feature is available on i8042prt ports (PS/2 
keyboards), while in Windows Vista and later, it is available on USB 
keyboards as well. It can also be fully configured to accommodate 
various keyboards using the registry key settings.

Two preparations must be made before this can be done:

   1. If you wish a crash dump file to be written, you must enable such
      dump files, choose the path and file name, and select the size of
      the dump file. For details, see Enabling a Kernel-Mode Dump File
      <r10_dump_files_d9e8043c-8489-4bd3-8f95-b76c2f8a4bf9.xml.htm>.
   2. With PS/2 keyboards, you must enable the keyboard-initiated crash
      in the registry. In the registry key
     
*HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters*,
      create a value named *CrashOnCtrlScroll*, and set it equal to
      REG_DWORD 0x1 (or any nonzero value).
   3. With USB keyboards, you must set the registry key
      *HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters*
      and create a value named *CrashOnCtrlScroll*, and set it equal to
      REG_DWORD 0x1 (or any nonzero value).

      *Note*  There is a limitation with the /Kbdhid.sys/ driver that
      allows you to generate the memory dump process by using a USB
      keyboard. The CTRL+SCROLL LOCK+SCROLL LOCK keyboard shortcut does
      not work if the computer stops responding at a high interrupt
      request level (IRQL). This limitation exists because the
      /Kbdhid.sys/ driver operates at a lower IRQL than the i8042prt.sys
      driver. For more information on using this feature with the USB
      keyboards, refer to the article  Generate a memory dump file by
      using the keyboard <http://go.microsoft.com/fwlink/?linkid=106065>.

The system must be rebooted before these changes will take effect.

After this has been done, the keyboard crash can be initiated as 
follows. Hold down the /rightmost /CTRL key, and press the SCROLL LOCK/ 
/key twice.

It is possible for a system to freeze in such a way that this 
CTRL+SCROLL LOCK+SCROLL LOCK sequence will not work. However, this 
should be a very rare occurrence. The CTRL+SCROLL LOCK+SCROLL LOCK crash 
initiation will work even in many instances where CTRL+ALT+DELETE does 
not work.

The system then calls *KeBugCheck* and issues bug check 0xE2 
<t07_bugs_e0_84753fee-8a24-4049-bb27-aa07a5fc60de.xml.htm> 
(MANUALLY_INITIATED_CRASH). Unless crash dumps have been disabled, a 
crash dump file is written at this point.

If a kernel debugger is attached to the frozen machine, the machine will 
break into the kernel debugger after the crash dump file has been written.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel