Bug 1230558 - BSOD - virtio-win - viostor.sys - DRIVER_IRQL_NOT_LESS_OR_EQUAL
Summary: BSOD - virtio-win - viostor.sys - DRIVER_IRQL_NOT_LESS_OR_EQUAL
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtio-win
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-11 07:19 UTC by dbp
Modified: 2015-06-30 09:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 09:05:30 UTC
Embargoed:

Attachments (Terms of Use)

Description dbp 2015-06-11 07:19:00 UTC 
Description of problem: Random BSOD when using virtio storage driver.  Both guest and host are in high I/O loading.

Version-Release number of selected component (if applicable):
Guest OS: Windows 2008 R2
Guest driver: virtio-win-0.1.96

How reproducible: Before installing virtio storage driver, system up for 1 month without problem.  After installed virtio storage driver, system BSOD twice, each time up time about 1 week.  After uninstalled virtio storage driver, system does not have BSOD anymore.

Steps to Reproduce:
1. Install Windows 2008 R2 with IDE driver
2. Add new disk with virtio bus
3. Restart Windows, Windows found new hardware, install virtio-win storage driver

Actual results:
BSOD after about 1 week

Expected results:
No BSOD

Additional info:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000468, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88000feaa5a, address which referenced memory
 
Debugging Details:
------------------
 
 
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800018ff100
GetUlongFromAddress: unable to read from fffff800018ff1c0
 0000000000000468 Nonpaged pool
 
CURRENT_IRQL:  2
 
FAULTING_IP:
viostor+2a5a
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h]
 
CUSTOMER_CRASH_COUNT:  1
 
DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT_SERVER
 
BUGCHECK_STR:  0xD1
 
PROCESS_NAME:  System
 
TRAP_FRAME:  fffff880009cc990 -- (.trap 0xfffff880009cc990)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8001ae6800
rdx=fffffa8001ae5102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88000feaa5a rsp=fffff880009ccb20 rbp=0000000000000001
 r8=0000000000000006  r9=fffffa8001ae6840 r10=fffff8800127e300
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
viostor+0x2a5a:
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h] ds:00000000`00000468=????????
Resetting default scope
 
LAST_CONTROL_TRANSFER:  from fffff800016c1fe9 to fffff800016c2a40
 
STACK_TEXT:  
fffff880`009cc848 fffff800`016c1fe9 : 00000000`0000000a 00000000`00000468 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`009cc850 fffff800`016c0c60 : ffffffff`00002001 fffff880`00000001 ffffffff`ff9bf477 fffffa80`01ae30c8 : nt!KiBugCheckDispatch+0x69
fffff880`009cc990 fffff880`00feaa5a : 000001a0`051240f3 fffffa80`01ae30c8 00000000`00000001 00000000`00000002 : nt!KiPageFault+0x260
fffff880`009ccb20 000001a0`051240f3 : fffffa80`01ae30c8 00000000`00000001 00000000`00000002 fffff880`009ccb58 : viostor+0x2a5a
fffff880`009ccb28 fffffa80`01ae30c8 : 00000000`00000001 00000000`00000002 fffff880`009ccb58 00000000`00000018 : 0x000001a0`051240f3
fffff880`009ccb30 00000000`00000001 : 00000000`00000002 fffff880`009ccb58 00000000`00000018 00000000`00000001 : 0xfffffa80`01ae30c8
fffff880`009ccb38 00000000`00000002 : fffff880`009ccb58 00000000`00000018 00000000`00000001 fffff800`016cc2f6 : 0x1
fffff880`009ccb40 fffff880`009ccb58 : 00000000`00000018 00000000`00000001 fffff800`016cc2f6 00000000`00369e99 : 0x2
fffff880`009ccb48 00000000`00000018 : 00000000`00000001 fffff800`016cc2f6 00000000`00369e99 00000000`00000000 : 0xfffff880`009ccb58
fffff880`009ccb50 00000000`00000001 : fffff800`016cc2f6 00000000`00369e99 00000000`00000000 00000000`00000001 : 0x18
fffff880`009ccb58 fffff800`016cc2f6 : 00000000`00369e99 00000000`00000000 00000000`00000001 00000000`00000000 : 0x1
fffff880`009ccb60 fffff800`016ba74a : fffff880`009b9180 fffff880`009c3fc0 00000000`00000000 fffff880`00fea9c0 : nt!PoIdle+0x5a7
fffff880`009ccc40 00000000`00000000 : fffff880`009cd000 fffff880`009c7000 fffff880`009ccc00 00000000`00000000 : nt!KiIdleLoop+0x5a
 
 
STACK_COMMAND:  kb
 
FOLLOWUP_IP:
viostor+2a5a
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h]
 
SYMBOL_STACK_INDEX:  3
 
SYMBOL_NAME:  viostor+2a5a
 
FOLLOWUP_NAME:  MachineOwner
 
MODULE_NAME: viostor
 
IMAGE_NAME:  viostor.sys
 
DEBUG_FLR_IMAGE_TIMESTAMP:  50182266
 
FAILURE_BUCKET_ID:  X64_0xD1_viostor+2a5a
 
BUCKET_ID:  X64_0xD1_viostor+2a5a
 
Followup: MachineOwner
---------
 
1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000468, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88000feaa5a, address which referenced memory
 
Debugging Details:
------------------
 
 
READ_ADDRESS:  0000000000000468 Nonpaged pool
 
CURRENT_IRQL:  2
 
FAULTING_IP:
viostor+2a5a
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h]
 
CUSTOMER_CRASH_COUNT:  1
 
DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT_SERVER
 
BUGCHECK_STR:  0xD1
 
PROCESS_NAME:  System
 
TRAP_FRAME:  fffff880009cc990 -- (.trap 0xfffff880009cc990)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8001ae6800
rdx=fffffa8001ae5102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88000feaa5a rsp=fffff880009ccb20 rbp=0000000000000001
 r8=0000000000000006  r9=fffffa8001ae6840 r10=fffff8800127e300
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
viostor+0x2a5a:
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h] ds:00000000`00000468=????????
Resetting default scope
 
LAST_CONTROL_TRANSFER:  from fffff800016c1fe9 to fffff800016c2a40
 
STACK_TEXT:  
fffff880`009cc848 fffff800`016c1fe9 : 00000000`0000000a 00000000`00000468 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`009cc850 fffff800`016c0c60 : ffffffff`00002001 fffff880`00000001 ffffffff`ff9bf477 fffffa80`01ae30c8 : nt!KiBugCheckDispatch+0x69
fffff880`009cc990 fffff880`00feaa5a : 000001a0`051240f3 fffffa80`01ae30c8 00000000`00000001 00000000`00000002 : nt!KiPageFault+0x260
fffff880`009ccb20 000001a0`051240f3 : fffffa80`01ae30c8 00000000`00000001 00000000`00000002 fffff880`009ccb58 : viostor+0x2a5a
fffff880`009ccb28 fffffa80`01ae30c8 : 00000000`00000001 00000000`00000002 fffff880`009ccb58 00000000`00000018 : 0x000001a0`051240f3
fffff880`009ccb30 00000000`00000001 : 00000000`00000002 fffff880`009ccb58 00000000`00000018 00000000`00000001 : 0xfffffa80`01ae30c8
fffff880`009ccb38 00000000`00000002 : fffff880`009ccb58 00000000`00000018 00000000`00000001 fffff800`016cc2f6 : 0x1
fffff880`009ccb40 fffff880`009ccb58 : 00000000`00000018 00000000`00000001 fffff800`016cc2f6 00000000`00369e99 : 0x2
fffff880`009ccb48 00000000`00000018 : 00000000`00000001 fffff800`016cc2f6 00000000`00369e99 00000000`00000000 : 0xfffff880`009ccb58
fffff880`009ccb50 00000000`00000001 : fffff800`016cc2f6 00000000`00369e99 00000000`00000000 00000000`00000001 : 0x18
fffff880`009ccb58 fffff800`016cc2f6 : 00000000`00369e99 00000000`00000000 00000000`00000001 00000000`00000000 : 0x1
fffff880`009ccb60 fffff800`016ba74a : fffff880`009b9180 fffff880`009c3fc0 00000000`00000000 fffff880`00fea9c0 : nt!PoIdle+0x5a7
fffff880`009ccc40 00000000`00000000 : fffff880`009cd000 fffff880`009c7000 fffff880`009ccc00 00000000`00000000 : nt!KiIdleLoop+0x5a
 
 
STACK_COMMAND:  kb
 
FOLLOWUP_IP:
viostor+2a5a
fffff880`00feaa5a 418b842468040000 mov     eax,dword ptr [r12+468h]
 
SYMBOL_STACK_INDEX:  3
 
SYMBOL_NAME:  viostor+2a5a
 
FOLLOWUP_NAME:  MachineOwner
 
MODULE_NAME: viostor
 
IMAGE_NAME:  viostor.sys
 
DEBUG_FLR_IMAGE_TIMESTAMP:  50182266
 
FAILURE_BUCKET_ID:  X64_0xD1_viostor+2a5a
 
BUCKET_ID:  X64_0xD1_viostor+2a5a
Comment 1 Vadim Rozenfeld 2015-06-11 09:50:06 UTC 
Can you try the latest build available at  http://alt.fedoraproject.org/pub/alt/virtio-wi (should be 105)?

Thanks,
Vadim.
Comment 2 dbp 2015-06-30 09:05:30 UTC 
up-time for over 8 days without BSOD under build 105.
Note You need to log in before you can comment on or make changes to this bug.