> From: Marcelo Tosatti [mailto:mtosatti@xxxxxxxxxx] > Sent: Thursday, March 19, 2015 1:52 AM > > Generate a Windows dump? > > https://support.microsoft.com/en-us/kb/254649 > > https://support.microsoft.com/en-us/kb/972110 > Step 7: Generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system > > (you can inject NMIs via QEMU monitor). Hi, thanks for the hint. Somehow I felt I needed to BSOD it, but I didn't know where to look. It happened again today (so about 14 days later after I enabled NMI crash dump). I got kernel memory dump. Stack trace shows (I've enabled noisy sym): STACK_TEXT: 8054e610 806eaea3 00000080 004f4454 00000000 nt!KeBugCheckEx+0x1b 8054e65c 805426c4 00000000 ba33c0c8 805517da hal!HalHandleNMI+0x195 8054e65c 80501fdd 00000000 ba33c0c8 805517da nt!KiTrap02+0xf8 b36dcaf0 804fb39d 0000000e 00000001 00000004 nt!KiIpiStallOnPacketTargets+0x27 b36dcb08 8054a690 00000001 00000001 8a852d20 nt!KeFlushEntireTb+0x79 b36dcb2c 80509247 0007e901 00000000 00000000 nt!MiReserveSystemPtes+0x70 b36dcb74 b753d9f8 8a852d20 00000000 00000001 nt!MmMapLockedPagesSpecifyCache+0x101 b36dcb94 b75337f8 8a852d20 00000010 8a2cb2a4 tcpip!TcpipBufferVirtualAddress+0x24 b36dcbb4 b75589f5 00022885 8a2cb230 0000403f tcpip!XsumSendChain+0x44 b36dcc00 b7534d35 86e36a9a 00004000 8a80abd4 tcpip!TCPSend+0x4f1 b36dcc28 b75344a5 00000001 00000000 00004000 tcpip!TdiSend+0x1c7 b36dcc5c b74bc14a 8a80a990 8ad2ce4c 8a80a990 tcpip!TCPSendData+0x83 b36dcc88 aff10eb4 8a8a5528 8a80a990 8a804000 netbt!NTSend+0x1e1 b36dccb0 aff1c8b2 8a80ac98 aff185ef 00000000 srv!SrvStartSend2+0x16e b36dccdc aff55dcd aff211f4 8a80a020 8ab4c718 srv!SrvFsdRestartLargeReadAndX+0x2ae b36dcd7c aff10836 8a80a028 8ab4c6e0 aff250d8 srv!SrvSmbReadAndX+0x3fe b36dcd88 aff250d8 00000000 8ab41528 00000000 srv!SrvProcessSmb+0xb7 b36dcdac 805cffee 8a80a020 00000000 00000000 srv!WorkerThread+0x11e b36dcddc 8054620e aff25024 8ab4c6e0 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 So the function in question is KiIpiStallOnPacketTargets before it went into NMI crash handler (see the return address on KiTrap02), that's where the machine was frozen again today: # virsh qemu-monitor-command --hmp DBserver 'info cpus' * CPU #0: pc=0x0000000080501fdd thread_id=6675 CPU #1: pc=0x000000008051afc1 thread_id=6676 CPU #2: pc=0x0000000080545e6e thread_id=6677 CPU #3: pc=0x0000000080545e6e thread_id=6678 I have to mention that this particular machine is a P2V converted XP. The original physical machine had a Core2Quad already so there wasn't any need to change HAL or kernel image. I believe it uses ntkrpamp kernel image (that's what was listed in the debugger). I didn't do anything special during the conversion, switched to IDE and then installed virtio drivers. There doesn't seem to be any leftover driver from the phys machine in the stack trace... Is there anything else I could check that could help debug this issue? Best Regards, Saso Slavicic -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
