Rich (BB code):
ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
An attempt was made to write to readonly memory. The guilty driver is on the
stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff803799a7836, Virtual address for the attempted write.
Arg2: 8900000fd21d5121, PTE contents.
Arg3: ffff9e8f97908c20, (reserved) << Address of trap frame
Arg4: 000000000000000a, (reserved)
As the bugcheck description implies, a driver has attempted to write to a region of readonly memory. You can usually run
!pte with the first parameter and it will show that the address in question has the write bit cleared. The third parameter points to the trap frame of where we crashed. It usually isn't of much interest other than to see where we crashed.
Rich (BB code):
54: kd> !process
PROCESS ffff8c02ef625080
SessionId: 1 Cid: 225c Peb: 00775000 ParentCid: 379c
DirBase: 450aff000 ObjectTable: ffffa00c6e80f000 HandleCount: 1189.
Image: iVMS-4200.Framework.C.exe
Rich (BB code):
54: kd> knL
# Child-SP RetAddr Call Site
00 ffff9e8f`97908a28 fffff803`29e75cee nt!KeBugCheckEx
01 ffff9e8f`97908a30 fffff803`29c9f63f nt!MiRaisedIrqlFault+0x142952
02 ffff9e8f`97908a80 fffff803`29e05a5e nt!MmAccessFault+0x4ef
03 ffff9e8f`97908c20 fffff803`29c88ca0 nt!KiPageFault+0x35e
04 ffff9e8f`97908db0 fffff803`29c86ccb nt!KiTryUnwaitThread+0x50
05 ffff9e8f`97908e10 fffff803`29c862f9 nt!KeSetEvent+0x19b
06 ffff9e8f`97908ea0 fffff803`29c0ec90 nt!IopCompleteRequest+0x389
07 ffff9e8f`97908f60 fffff803`29dfbc00 nt!KiDeliverApc+0x1b0
08 ffff9e8f`97909010 fffff803`799a2089 nt!KiApcInterrupt+0x2f0
09 ffff9e8f`979091a0 fffff803`799ac253 hidusb!HumGetDescriptorRequest+0x269
0a ffff9e8f`97909210 fffff803`799a1507 hidusb!HumGetStringDescriptor+0xe3
0b ffff9e8f`97909290 fffff803`799c3989 hidusb!HumInternalIoctl+0x3e7
0c ffff9e8f`97909580 fffff803`799d5470 HIDCLASS!HidpCallDriver+0xb9
0d ffff9e8f`979095f0 fffff803`799d820b HIDCLASS!HidpCallDriverAsynchronous+0x2c
0e ffff9e8f`97909620 fffff803`799c72f2 HIDCLASS!HidpGetDeviceString+0xd7
0f ffff9e8f`97909670 fffff803`799c2661 HIDCLASS!HidpIrpMajorDeviceControl+0xc72
10 ffff9e8f`97909770 fffff803`29c8f835 HIDCLASS!HidpMajorHandler+0x191
11 ffff9e8f`97909800 fffff803`2a077418 nt!IofCallDriver+0x55
12 ffff9e8f`97909840 fffff803`2a077217 nt!IopSynchronousServiceTail+0x1a8
13 ffff9e8f`979098e0 fffff803`2a076596 nt!IopXxxControlFile+0xc67
14 ffff9e8f`97909a20 fffff803`29e092b8 nt!NtDeviceIoControlFile+0x56
15 ffff9e8f`97909a90 00000000`76e81cfc nt!KiSystemServiceCopyEnd+0x28
16 00000000`1b22efd8 00000000`76e81933 wow64cpu!CpupSyscallStub+0xc
17 00000000`1b22efe0 00000000`76e811b9 wow64cpu!DeviceIoctlFileFault+0x31
18 00000000`1b22f090 00007fff`0b2338c9 wow64cpu!BTCpuSimulate+0x9
19 00000000`1b22f0d0 00007fff`0b2332bd wow64!RunCpuSimulation+0xd
1a 00000000`1b22f100 00007fff`0b344f79 wow64!Wow64LdrpInitialize+0x12d
1b 00000000`1b22f3b0 00007fff`0b344b63 ntdll!LdrpInitialize+0x3fd
1c 00000000`1b22f450 00007fff`0b344b0e ntdll!LdrpInitialize+0x3b
1d 00000000`1b22f480 00000000`00000000 ntdll!LdrInitializeThunk+0xe
We examine the call stack, we can see that a IOTCL was initiated by the iVMS software to a USB-based human interface device (HID). So, we've quickly established where the issue possibly lies. Let's investigate a little further and try and find out what particular device the software is sending an IOTCL request to.
Rich (BB code):
54: kd> !stack -p
Call Stack : 30 frames
## Stack-Pointer Return-Address Call-Site
00 ffff9e8f97908a28 fffff80329e75cee nt!KeBugCheckEx+0
Parameter[0] = 00000000000000be
Parameter[1] = fffff803799a7836
Parameter[2] = 8900000fd21d5121
Parameter[3] = ffff9e8f97908c20
01 ffff9e8f97908a30 fffff80329c9f63f nt!MiRaisedIrqlFault+142952 (perf)
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
02 ffff9e8f97908a80 fffff80329e05a5e nt!MmAccessFault+4ef (perf)
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
03 ffff9e8f97908c20 fffff80329c88ca0 nt!KiPageFault+35e
Parameter[0] = ffffb081b8d77180
Parameter[1] = 0000000000000000
Parameter[2] = 0000000000000100
Parameter[3] = 0000000000000000
04 ffff9e8f97908db0 fffff80329c86ccb nt!KiTryUnwaitThread+50
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
[...]
09 ffff9e8f979091a0 fffff803799ac253 hidusb!HumGetDescriptorRequest+269 (perf)
Parameter[0] = ffff8c02ec8923f0
Parameter[1] = 000000000000000b
Parameter[2] = 0000000000000003
Parameter[3] = ffff9e8f97909298
0a ffff9e8f97909210 fffff803799a1507 hidusb!HumGetStringDescriptor+e3 (perf)
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
0b ffff9e8f97909290 fffff803799c3989 hidusb!HumInternalIoctl+3e7
Parameter[0] = ffff8c02ec8923f0
Parameter[1] = 0000000000000409
Parameter[2] = (unknown)
Parameter[3] = (unknown)
0c ffff9e8f97909580 fffff803799d5470 HIDCLASS!HidpCallDriver+b9 (perf)
Parameter[0] = ffff8c02ec8923f0
Parameter[1] = ffff8c02e4e50460
Parameter[2] = (unknown)
Parameter[3] = fffff803799d5410
0d ffff9e8f979095f0 fffff803799d820b HIDCLASS!HidpCallDriverAsynchronous+2c
Parameter[0] = (unknown)
Parameter[1] = ffff8c02e4e50460
Parameter[2] = (unknown)
Parameter[3] = (unknown)
0e ffff9e8f97909620 fffff803799c72f2 HIDCLASS!HidpGetDeviceString+d7
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
0f ffff9e8f97909670 fffff803799c2661 HIDCLASS!HidpIrpMajorDeviceControl+c72
Parameter[0] = (unknown)
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
10 ffff9e8f97909770 fffff80329c8f835 HIDCLASS!HidpMajorHandler+191 (perf)
Parameter[0] = ffff8c02f0eb9540
Parameter[1] = ffff8c02e4e50460
Parameter[2] = (unknown)
Parameter[3] = (unknown)
11 ffff9e8f97909800 fffff8032a077418 nt!IofCallDriver+55
Parameter[0] = ffff8c02f0eb93f0 << Device object
Parameter[1] = ffff8c02e4e50460 << IRP
Parameter[2] = (unknown)
Parameter[3] = (unknown)
[...]
We know the
nt!IoCallDriver function takes two parameters, one of which is the device object which the IRP is being sent to. The second parameter is the IRP itself and isn't of much interest here. It is simply the IOCTL request from earlier. Let's examine the device object itself.
Rich (BB code):
54: kd> !devobj ffff8c02f0eb93f0
Device object (ffff8c02f0eb93f0) is for:
00000103 \Driver\HidUsb DriverObject ffff8c02e12d4e20
Current Irp 00000000 RefCount 4 Type 00000022 Flags 00003050
SecurityDescriptor ffffa00c25d42a20 DevExt ffff8c02f0eb9540 DevObjExt ffff8c02f0eb9e48 DevNode ffff8c02ef32dc80
ExtensionFlags (0000000000)
Characteristics (0x00000080) FILE_AUTOGENERATED_DEVICE_NAME
Device queue is not busy.
Now, if we examine the device node to obtain the device instance string, we'll be able to see which HID device the device object belongs to.
Rich (BB code):
54: kd> !devnode ffff8c02ef32dc80
DevNode 0xffff8c02ef32dc80 for PDO 0xffff8c02f0eb93f0
Parent 0xffff8c02e71a6cc0 Sibling 0xffff8c02dce18c80 Child 0000000000
InstancePath is "HID\VID_04D9&PID_FA50&MI_02&Col01\8&1516a161&0&0000"
TargetDeviceNotify List - f 0xffffa00c5c7c2110 b 0xffffa00c5c7c2110
We could lookup the device instance string and see what device it belongs to. However, we can gather further evidence from the dump file, that is particular device is what is having issues with the iVMS software. Let's dump the call stack using
!dpx to gather additional information such as any strings which have been pushed onto it. There is one particular string of interest and in a few moments you'll see why.
Rich (BB code):
54: kd> !PDE.da ffff8c02e95c8000
HID00000014
This string is used to identify a particular HID object within the HID device tree. We can dump the said tree by loading the hidkd.dll (part of WinDbg installation) and then using the
!hidtree command.
Rich (BB code):
54: kd> !hidtree
HID Device Tree
================================================================================
FDO VendorID:0x048D(ITE Tech Inc.) ProductID:0x8297 Version:0x0003
!hidfdo 0xffff8c02f56d13f0
PowerStates: S0/D3 | 0n0
dt FDO_EXTENSION 0xffff8c02f56d1560
!devnode 0xffff8c02fa8e7ce0 | DeviceNodeStarted (0n776)
InstancePath: USB\VID_048D&PID_8297\9&2935eb80&0&2
IFR Log: !rcdrlogdump HIDCLASS -a 0xFFFF8C02E1B99000
PDO Vendor-defined (0xFF89) | 0x10
!hidpdo 0xffff8c02ef618060
Power States: S0/D2 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02ef6181d0
!devnode 0xffff8c02ec420cc0 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_048D&PID_8297&Col01\a&39721238&0&0000
PDO Vendor-defined (0xFF89) | 0xCC
!hidpdo 0xffff8c02ec5f8060
Power States: S0/D2 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02ec5f81d0
!devnode 0xffff8c02f0243cc0 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_048D&PID_8297&Col02\a&39721238&0&0001
--------------------------------------------------------------------------------
FDO VendorID:0x04D9(Holtek Semiconductor, Inc.) ProductID:0xFA50 Version:0x0201
!hidfdo 0xffff8c02ec8923f0
PowerStates: S0/D0 | 0n0
dt FDO_EXTENSION 0xffff8c02ec892560
!devnode 0xffff8c02e71a6cc0 | DeviceNodeStarted (0n776)
InstancePath: USB\VID_04D9&PID_FA50&MI_02\7&376541d6&0&0002
IFR Log: !rcdrlogdump HIDCLASS -a 0xFFFF8C02E95C8000
PDO Consumer (0x0C) | Consumer Control (0x01)
!hidpdo 0xffff8c02f0eb93f0
Power States: S0/D0 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02f0eb9560
!devnode 0xffff8c02ef32dc80 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_04D9&PID_FA50&MI_02&Col01\8&1516a161&0&0000
PDO Vendor-defined (0xFFA0) | 0x01
!hidpdo 0xffff8c02f07973f0
Power States: S0/D0 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02f0797560
!devnode 0xffff8c02dce18c80 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_04D9&PID_FA50&MI_02&Col02\8&1516a161&0&0001
--------------------------------------------------------------------------------
FDO VendorID:0x04D9(Holtek Semiconductor, Inc.) ProductID:0xFA50 Version:0x0201
!hidfdo 0xffff8c02f03d9060
PowerStates: S0/D0 | 0n0
dt FDO_EXTENSION 0xffff8c02f03d91d0
!devnode 0xffff8c02f0c4dcb0 | DeviceNodeStarted (0n776)
InstancePath: USB\VID_04D9&PID_FA50&MI_01\7&376541d6&0&0001
IFR Log: !rcdrlogdump HIDCLASS -a 0xFFFF8C02E18E3000
PDO Generic Desktop Controls (0x01) | Keyboard (0x06)
!hidpdo 0xffff8c02ededd3f0
Power States: S0/D0 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02ededd560
!devnode 0xffff8c02eadbbcc0 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_04D9&PID_FA50&MI_01\8&38eddf23&0&0000
--------------------------------------------------------------------------------
FDO VendorID:0x04D9(Holtek Semiconductor, Inc.) ProductID:0xFA50 Version:0x0201
!hidfdo 0xffff8c02ef7f9060
PowerStates: S0/D0 | 0n0
dt FDO_EXTENSION 0xffff8c02ef7f91d0
!devnode 0xffff8c02ef1f9cb0 | DeviceNodeStarted (0n776)
InstancePath: USB\VID_04D9&PID_FA50&MI_00\7&376541d6&0&0000
IFR Log: !rcdrlogdump HIDCLASS -a 0xFFFF8C02E18BC000
PDO Generic Desktop Controls (0x01) | Mouse (0x02)
!hidpdo 0xffff8c02efa271f0
Power States: S0/D0 | COLLECTION_STATE_RUNNING (0n3)
dt PDO_EXTENSION 0xffff8c02efa27360
!devnode 0xffff8c02ebf53cc0 | DeviceNodeStarted (0n776)
Instance Path:HID\VID_04D9&PID_FA50&MI_00\8&212a52de&0&0000
[...]
Notice the same device identification string and device node? Let's dump the function device object for the device node and we'll see the same string from the call stack.
Rich (BB code):
54: kd> !hidfdo 0xffff8c02ec8923f0
FDO 0xffff8c02ec8923f0 (!devobj/!devstack)
==============================================
Name : \Device\_HID00000014
Vendor ID : 0x04D9(Holtek Semiconductor, Inc.)
Product ID : 0xFA50
Version Number : 0x0201
Is Present? : Y
According to the user, the device was for Anker DS-2368 gaming mouse and switching to a different mouse appeared to resolve the issue. Holtek - according to Wikipedia - appear to provide electronic components for a number of different companies and therefore it is very likely the Anker mouse was using components from them.
[SOLVED] - iVMS driving me crazy
