none
PUCHAR variable causes system crash RRS feed

  • Question

  • Hi, I am working on an upper volume filter driver.

    Is the below code correct?

    What could be the solution for this?

    UCHAR block_bit;
    PUCHAR tmp1 = NULL;
    
    *tmp1 = (*tmp1) | (1<<block_bit);

    Its continuously giving me these 2 errors when debugged through win dbg, it is crashing my system at boot time,

    Access violation - code c0000005 (!!! second chance !!!) mydriver!mydriverReadWrite+0x1b3: 88decfb3 0fb610 movzx edx,byte ptr [eax]

    OR

    PAGE_FAULT_IN_NONPAGED_AREA (50)
    Invalid system memory was referenced.  This cannot be protected by try-except,
    it must be protected by a Probe.  Typically the address is just plain bad or it
    is pointing at freed memory.
    Arguments:
    Arg1: d9c4e199, memory referenced.
    Arg2: 00000000, value 0 = read operation, 1 = write operation.
    Arg3: 88b29fb3, If non-zero, the instruction address which referenced the bad memory
    	address.
    Arg4: 00000002, (reserved)
    
    Debugging Details:
    ------------------
    
    
    READ_ADDRESS:  d9c4e199 
    
    FAULTING_IP: 
    mydriver!mydriverReadWrite+1b3 [e:\program files\myproject\mydriver.c @ 1864]
    88b29fb3 0fb610          movzx   edx,byte ptr [eax]
    
    MM_INTERNAL_CODE:  2
    
    IMAGE_NAME:  mydriver.sys
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  5155a266
    
    MODULE_NAME: mydriver
    
    FAULTING_MODULE: 88b28000 mydriver
    
    DEFAULT_BUCKET_ID:  INTEL_CPU_MICROCODE_ZERO
    
    BUGCHECK_STR:  0x50
    
    PROCESS_NAME:  System
    
    CURRENT_IRQL:  2
    
    TRAP_FRAME:  8a9a26c8 -- (.trap 0xffffffff8a9a26c8)
    ErrCode = 00000000
    eax=d9c4e199 ebx=00000000 ecx=00000000 edx=d9c4e199 esi=85487d7c edi=85487d58
    eip=88b29fb3 esp=8a9a273c ebp=8a9a27bc iopl=0         nv up ei ng nz na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210286
    mydriver!mydriverReadWrite+0x1b3:
    88b29fb3 0fb610          movzx   edx,byte ptr [eax]         ds:0023:d9c4e199=??
    Resetting default scope
    
    LAST_CONTROL_TRANSFER:  from 826e0083 to 8267c110
    
    STACK_TEXT:  
    8a9a2214 826e0083 00000003 2573c18e 00000065 nt!RtlpBreakWithStatusInstruction
    8a9a2264 826e0b81 00000003 00003ff8 d9c4e199 nt!KiBugCheckDebugBreak+0x1c
    8a9a2628 8268f41b 00000050 d9c4e199 00000000 nt!KeBugCheck2+0x68b
    8a9a26b0 826423d8 00000000 d9c4e199 00000000 nt!MmAccessFault+0x106
    8a9a26b0 88b29fb3 00000000 d9c4e199 00000000 nt!KiTrap0E+0xdc
    8a9a27bc 82638593 85428e08 85487bc8 00000200 mydriver!mydriverReadWrite+0x1b3 [e:\program files\myproject\mydriver.c @ 1864]
    8a9a27d4 8882c41c c000014f 85428e08 00000000 nt!IofCallDriver+0x63
    8a9a2800 8882d4d5 85428e08 8a9a282c 00000200 Fs_Rec!FsRecReadBlock+0x96
    8a9a283c 8882c0be 854ab000 854332d0 853aeef8 Fs_Rec!ExFatRecFsControl+0x73
    8a9a2850 82638593 853aeef8 854332d0 82739e00 Fs_Rec!FsRecFsControl+0x60
    8a9a2868 8279bd29 82a15808 85422730 82a1585c nt!IofCallDriver+0x63
    8a9a28cc 826a95eb 85422730 846bca00 00000000 nt!IopMountVolume+0x1d8
    8a9a2904 82847b9b 846bca48 8a9a2a30 8a9a29c8 nt!IopCheckVpbMounted+0x64
    8a9a29e8 82827ac5 85422730 846bdde8 8463dc60 nt!IopParseDevice+0x7c9
    8a9a2a64 82837ed6 00000000 8a9a2ab8 00000240 nt!ObpLookupObjectName+0x4fa
    8a9a2ac0 8282e9b4 8a9a2c40 846bdde8 84631000 nt!ObOpenObjectByName+0x165
    8a9a2b3c 82834b3a 8a9a2c8c 00120089 8a9a2c40 nt!IopCreateFile+0x673
    8a9a2b84 8263f1ea 8a9a2c8c 00120089 8a9a2c40 nt!NtOpenFile+0x2a
    8a9a2b84 8263d561 8a9a2c8c 00120089 8a9a2c40 nt!KiFastCallEntry+0x12a
    8a9a2c14 88daa522 8a9a2c8c 00120089 8a9a2c40 nt!ZwOpenFile+0x11
    8a9a2c90 88db328a 854280d8 00000000 00000000 volsnap!VspOpenControlBlockFile+0x108
    8a9a2d1c 88db3fe4 854280d8 85438c94 853dfc0c volsnap!VspOpenFilesAndValidateSnapshots+0x2e
    8a9a2d34 88d9ff33 85438c90 00000000 8544dd48 volsnap!VspSetIgnorableBlocksInBitmapWorker+0x40
    8a9a2d50 8280af5e 853dfcfc 2573ce7a 00000000 volsnap!VspWorkerThread+0x83
    8a9a2d90 826b2219 88d9feb0 854634e8 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
    
    
    STACK_COMMAND:  kb
    
    FOLLOWUP_IP: 
    mydriver!mydriverReadWrite+1b3 [e:\program files\myproject\mydriver.c @ 1864]
    88b29fb3 0fb610          movzx   edx,byte ptr [eax]
    
    FAULTING_SOURCE_CODE:  
      1860: 
      1861: 		/* Select index from the bitmap */
      1862: 		tmp1 = (Part_Infomation[i].mapcache)+block_byte;
      1863: 
    > 1864: 		*tmp1 = (*tmp1) | (1<<block_bit);
      1865: 		DbgPrint("\n");
      1866: 		DbgPrint("bitmap:");
      1867: 		for(l = 0; l < 500; l++)
      1868: 		{
      1869: 			DbgPrint("%d",*tmp1+l);
    
    
    SYMBOL_STACK_INDEX:  5
    
    SYMBOL_NAME:  mydriver!mydriverReadWrite+1b3
    
    FOLLOWUP_NAME:  MachineOwner
    
    FAILURE_BUCKET_ID:  0x50_mydriver!mydriverReadWrite+1b3
    
    BUCKET_ID:  0x50_mydriver!mydriverReadWrite+1b3
    
    Followup: MachineOwner
    ---------

    Friday, March 29, 2013 2:50 PM

Answers

  • You have a miscalculation of tmp1 because either Part_Infomation[i].mapcache is incorrect or block_byte is incorrect.  You have to debug it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, March 29, 2013 3:13 PM

All replies

  • This is not the shift that is failing it is that tmp1 does not point to a valid address.  Put a breakpoint on line 1862 in the above and check tmp1.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, March 29, 2013 2:59 PM
  • Hi, Thanks for your response.

    Sorry, I mean that only.

    Will add a break point and check the value.

    Friday, March 29, 2013 3:05 PM
  • You have a miscalculation of tmp1 because either Part_Infomation[i].mapcache is incorrect or block_byte is incorrect.  You have to debug it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, March 29, 2013 3:13 PM