Debugging Stop 0xBE - ATTEMPTED_WRITE_TO_READONLY_MEMORY

x BlueRobot

x BlueRobot

Administrator
Staff member
Joined
May 7, 2013
Posts
10,400
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
 
You must log in or register to reply here.

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top