zwReadFile crashes

Hi,

I have created a worker thread using “PsCreateSystemThread”. inside this
thread I am opening a file handle using zwOpenFile and it opens the file
successfully. Then I have allocated 1024 bytes of memory from paged pool
using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read 512
bytes from the file. It causes a system crash. I have also tried allocating
the memory from non-paged pool, but that also did not work.

I have read the bug-check analysis in WinDbg, it is showing Current IRQL as
2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL always?
What could be the reason for the crash?

Thanks a lot,
Lloyd

This is what WinDbg shows :-

BugCheck A, {96a9a000, 2, 1, 82879100}

Probably caused by : memory_corruption

nt!RtlpBreakWithStatusInstruction:
8289fbc0 cc int 3
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 96a9a000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
chips which support this level of status)
Arg4: 82879100, address which referenced memory

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’ overlap

WRITE_ADDRESS: 96a9a000 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!RtlFillMemoryUlong+10
82879100 f3ab rep stos dword ptr es:[edi]

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

PROCESS_NAME: System

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
ErrCode = 00000002
eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8
edi=96a9a000
eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
nt!RtlFillMemoryUlong+0x10:
82879100 f3ab rep stos dword ptr es:[edi]
Resetting default scope

LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0

STACK_TEXT:
960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
96007724 828ebaab 8435bed0 00000040 00000000 nt!MiAddViewsForSection+0xa0
96007830 828eb300 85dc8990 84296d70 96007870 nt!MmMapViewInSystemCache+0x28c
96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
960078e4 82aa968d 851f81d0 00000000 00000000 nt!CcGetVirtualAddress+0x1b1
9600792c 82a9f7bc 8435c2c0 00000000 00000000 nt!CcMapAndCopyFromCache+0x53
96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
96007b1c 877803cb 96007b3c 847de940 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
96007b8c 82a4c16e 847de940 8435c2c0 00000001
nt!IopSynchronousServiceTail+0x1f8
96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
96007d08 8f80fd86 843a3d60 843c17d8 00000000 FileMount!ReadFile_RAW+0xf8
[g:\project\cybercheck5\source
code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
96007d50 82a2ed16 84268ed8 424c0e81 00000000
FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source
code\virtualmount\filemount\filemount\workerthread.c @ 49]
96007d90 828d0159 8f80fc90 84268ed8 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

Are you holding a spinlock when you make the read call?

d

Bent from my phone


From: Lloydmailto:xxxxx
Sent: ?9/?11/?2014 11:56 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] zwReadFile crashes

Hi,

I have created a worker thread using “PsCreateSystemThread”. inside this thread I am opening a file handle using zwOpenFile and it opens the file successfully. Then I have allocated 1024 bytes of memory from paged pool using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read 512 bytes from the file. It causes a system crash. I have also tried allocating the memory from non-paged pool, but that also did not work.

I have read the bug-check analysis in WinDbg, it is showing Current IRQL as 2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL always? What could be the reason for the crash?

Thanks a lot,
Lloyd

This is what WinDbg shows :-

BugCheck A, {96a9a000, 2, 1, 82879100}

Probably caused by : memory_corruption

nt!RtlpBreakWithStatusInstruction:
8289fbc0 cc int 3
kd> !analyze -v


Bugcheck Analysis



IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 96a9a000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 82879100, address which referenced memory

Debugging Details:
------------------

OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’ overlap

WRITE_ADDRESS: 96a9a000 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!RtlFillMemoryUlong+10
82879100 f3ab rep stos dword ptr es:[edi]

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

PROCESS_NAME: System

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
ErrCode = 00000002
eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8 edi=96a9a000
eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!RtlFillMemoryUlong+0x10:
82879100 f3ab rep stos dword ptr es:[edi]
Resetting default scope

LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0

STACK_TEXT:
960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
96007724 828ebaab 8435bed0 00000040 00000000 nt!MiAddViewsForSection+0xa0
96007830 828eb300 85dc8990 84296d70 96007870 nt!MmMapViewInSystemCache+0x28c
96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
960078e4 82aa968d 851f81d0 00000000 00000000 nt!CcGetVirtualAddress+0x1b1
9600792c 82a9f7bc 8435c2c0 00000000 00000000 nt!CcMapAndCopyFromCache+0x53
96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
96007b1c 877803cb 96007b3c 847de940 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
96007b8c 82a4c16e 847de940 8435c2c0 00000001 nt!IopSynchronousServiceTail+0x1f8
96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
96007d08 8f80fd86 843a3d60 843c17d8 00000000 FileMount!ReadFile_RAW+0xf8 [g:\project\cybercheck5\source code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
96007d50 82a2ed16 84268ed8 424c0e81 00000000 FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source code\virtualmount\filemount\filemount\workerthread.c @ 49]
96007d90 828d0159 8f80fc90 84268ed8 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Yes, I am acquiring a spinlock using KeAcquireSpinLock.

Thanks,
Lloyd

On Fri, Sep 12, 2014 at 12:33 PM, Doron Holan
wrote:

> Are you holding a spinlock when you make the read call?
>
> d
>
> Bent from my phone
> ------------------------------
> From: Lloyd
> Sent: ‎9/‎11/‎2014 11:56 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] zwReadFile crashes
>
> Hi,
>
> I have created a worker thread using “PsCreateSystemThread”. inside this
> thread I am opening a file handle using zwOpenFile and it opens the file
> successfully. Then I have allocated 1024 bytes of memory from paged pool
> using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read 512
> bytes from the file. It causes a system crash. I have also tried allocating
> the memory from non-paged pool, but that also did not work.
>
> I have read the bug-check analysis in WinDbg, it is showing Current IRQL
> as 2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL
> always? What could be the reason for the crash?
>
> Thanks a lot,
> Lloyd
>
>
> This is what WinDbg shows :-
>
> BugCheck A, {96a9a000, 2, 1, 82879100}
>
> Probably caused by : memory_corruption
>
>
> nt!RtlpBreakWithStatusInstruction:
> 8289fbc0 cc int 3
> kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>

>
> IRQL_NOT_LESS_OR_EQUAL (a)
> 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 a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 96a9a000, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000001, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 82879100, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’ overlap
>
> WRITE_ADDRESS: 96a9a000 Paged pool
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!RtlFillMemoryUlong+10
> 82879100 f3ab rep stos dword ptr es:[edi]
>
> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>
> BUGCHECK_STR: 0xA
>
> PROCESS_NAME: System
>
> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
>
> TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
> ErrCode = 00000002
> eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8
> edi=96a9a000
> eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010206
> nt!RtlFillMemoryUlong+0x10:
> 82879100 f3ab rep stos dword ptr es:[edi]
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0
>
> STACK_TEXT:
> 960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
> 96007724 828ebaab 8435bed0 00000040 00000000 nt!MiAddViewsForSection+0xa0
> 96007830 828eb300 85dc8990 84296d70 96007870
> nt!MmMapViewInSystemCache+0x28c
> 96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
> 960078e4 82aa968d 851f81d0 00000000 00000000 nt!CcGetVirtualAddress+0x1b1
> 9600792c 82a9f7bc 8435c2c0 00000000 00000000 nt!CcMapAndCopyFromCache+0x53
> 96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
> 96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
> 96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
> 96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
> 96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
> 96007b1c 877803cb 96007b3c 847de940 00000000
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
> 96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
> 96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
> 96007b8c 82a4c16e 847de940 8435c2c0 00000001
> nt!IopSynchronousServiceTail+0x1f8
> 96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
> 96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
> 96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
> 96007d08 8f80fd86 843a3d60 843c17d8 00000000 FileMount!ReadFile_RAW+0xf8
> [g:\project\cybercheck5\source
> code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
> 96007d50 82a2ed16 84268ed8 424c0e81 00000000
> FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source
> code\virtualmount\filemount\filemount\workerthread.c @ 49]
> 96007d90 828d0159 8f80fc90 84268ed8 00000000 nt!PspSystemThreadStartup+0x9e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Thank you Doron,

Now I reread the KeAcquireSpinLock documentation, and understood the reason.

Thanks a lot,
Lloyd

On Fri, Sep 12, 2014 at 1:52 PM, Lloyd wrote:

> Yes, I am acquiring a spinlock using KeAcquireSpinLock.
>
> Thanks,
> Lloyd
>
> On Fri, Sep 12, 2014 at 12:33 PM, Doron Holan
> wrote:
>
>> Are you holding a spinlock when you make the read call?
>>
>> d
>>
>> Bent from my phone
>> ------------------------------
>> From: Lloyd
>> Sent: ‎9/‎11/‎2014 11:56 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] zwReadFile crashes
>>
>> Hi,
>>
>> I have created a worker thread using “PsCreateSystemThread”. inside
>> this thread I am opening a file handle using zwOpenFile and it opens the
>> file successfully. Then I have allocated 1024 bytes of memory from paged
>> pool using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read
>> 512 bytes from the file. It causes a system crash. I have also tried
>> allocating the memory from non-paged pool, but that also did not work.
>>
>> I have read the bug-check analysis in WinDbg, it is showing Current
>> IRQL as 2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL
>> always? What could be the reason for the crash?
>>
>> Thanks a lot,
>> Lloyd
>>
>>
>> This is what WinDbg shows :-
>>
>> BugCheck A, {96a9a000, 2, 1, 82879100}
>>
>> Probably caused by : memory_corruption
>>
>>
>> nt!RtlpBreakWithStatusInstruction:
>> 8289fbc0 cc int 3
>> kd> !analyze -v
>>
>> *****
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>
>>

>>
>> IRQL_NOT_LESS_OR_EQUAL (a)
>> 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 a kernel debugger is available get the stack backtrace.
>> Arguments:
>> Arg1: 96a9a000, memory referenced
>> Arg2: 00000002, IRQL
>> Arg3: 00000001, bitfield :
>> bit 0 : value 0 = read operation, 1 = write operation
>> bit 3 : value 0 = not an execute operation, 1 = execute operation (only
>> on chips which support this level of status)
>> Arg4: 82879100, address which referenced memory
>>
>> Debugging Details:
>> ------------------
>>
>>
>> OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’ overlap
>>
>> WRITE_ADDRESS: 96a9a000 Paged pool
>>
>> CURRENT_IRQL: 2
>>
>> FAULTING_IP:
>> nt!RtlFillMemoryUlong+10
>> 82879100 f3ab rep stos dword ptr es:[edi]
>>
>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>
>> BUGCHECK_STR: 0xA
>>
>> PROCESS_NAME: System
>>
>> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
>>
>> TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
>> ErrCode = 00000002
>> eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8
>> edi=96a9a000
>> eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na
>> pe nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> efl=00010206
>> nt!RtlFillMemoryUlong+0x10:
>> 82879100 f3ab rep stos dword ptr es:[edi]
>> Resetting default scope
>>
>> LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0
>>
>> STACK_TEXT:
>> 960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
>> 96007724 828ebaab 8435bed0 00000040 00000000 nt!MiAddViewsForSection+0xa0
>> 96007830 828eb300 85dc8990 84296d70 96007870
>> nt!MmMapViewInSystemCache+0x28c
>> 96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
>> 960078e4 82aa968d 851f81d0 00000000 00000000 nt!CcGetVirtualAddress+0x1b1
>> 9600792c 82a9f7bc 8435c2c0 00000000 00000000 nt!CcMapAndCopyFromCache+0x53
>> 96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
>> 96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
>> 96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
>> 96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
>> 96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
>> 96007b1c 877803cb 96007b3c 847de940 00000000
>> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
>> 96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
>> 96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
>> 96007b8c 82a4c16e 847de940 8435c2c0 00000001
>> nt!IopSynchronousServiceTail+0x1f8
>> 96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
>> 96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
>> 96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
>> 96007d08 8f80fd86 843a3d60 843c17d8 00000000 FileMount!ReadFile_RAW+0xf8
>> [g:\project\cybercheck5\source
>> code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
>> 96007d50 82a2ed16 84268ed8 424c0e81 00000000
>> FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source
>> code\virtualmount\filemount\filemount\workerthread.c @ 49]
>> 96007d90 828d0159 8f80fc90 84268ed8 00000000
>> nt!PspSystemThreadStartup+0x9e
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>

Well, don’t!
Why do you keep a spin lock during this operation. Read the documentation
of ZwReadFile and what keeping a spin lock does.
A spinlock raises to DPC. Read your data and then do the synchronization.
Why do you synch with spinlock in the first place ?

Gabriel.

On Fri, Sep 12, 2014 at 10:25 AM, Lloyd wrote:

> Thank you Doron,
>
> Now I reread the KeAcquireSpinLock documentation, and understood the
> reason.
>
> Thanks a lot,
> Lloyd
>
>
> On Fri, Sep 12, 2014 at 1:52 PM, Lloyd wrote:
>
>> Yes, I am acquiring a spinlock using KeAcquireSpinLock.
>>
>> Thanks,
>> Lloyd
>>
>> On Fri, Sep 12, 2014 at 12:33 PM, Doron Holan
>> wrote:
>>
>>> Are you holding a spinlock when you make the read call?
>>>
>>> d
>>>
>>> Bent from my phone
>>> ------------------------------
>>> From: Lloyd
>>> Sent: ‎9/‎11/‎2014 11:56 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: [ntdev] zwReadFile crashes
>>>
>>> Hi,
>>>
>>> I have created a worker thread using “PsCreateSystemThread”. inside
>>> this thread I am opening a file handle using zwOpenFile and it opens the
>>> file successfully. Then I have allocated 1024 bytes of memory from paged
>>> pool using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read
>>> 512 bytes from the file. It causes a system crash. I have also tried
>>> allocating the memory from non-paged pool, but that also did not work.
>>>
>>> I have read the bug-check analysis in WinDbg, it is showing Current
>>> IRQL as 2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL
>>> always? What could be the reason for the crash?
>>>
>>> Thanks a lot,
>>> Lloyd
>>>
>>>
>>> This is what WinDbg shows :-
>>>
>>> BugCheck A, {96a9a000, 2, 1, 82879100}
>>>
>>> Probably caused by : memory_corruption
>>>
>>>
>>> nt!RtlpBreakWithStatusInstruction:
>>> 8289fbc0 cc int 3
>>> kd> !analyze -v
>>>
>>> *****
>>>
>>>
>>> * Bugcheck Analysis
>>>
>>>
>>>
>>>
>>>

>>>
>>> IRQL_NOT_LESS_OR_EQUAL (a)
>>> 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 a kernel debugger is available get the stack backtrace.
>>> Arguments:
>>> Arg1: 96a9a000, memory referenced
>>> Arg2: 00000002, IRQL
>>> Arg3: 00000001, bitfield :
>>> bit 0 : value 0 = read operation, 1 = write operation
>>> bit 3 : value 0 = not an execute operation, 1 = execute operation (only
>>> on chips which support this level of status)
>>> Arg4: 82879100, address which referenced memory
>>>
>>> Debugging Details:
>>> ------------------
>>>
>>>
>>> OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’
>>> overlap
>>>
>>> WRITE_ADDRESS: 96a9a000 Paged pool
>>>
>>> CURRENT_IRQL: 2
>>>
>>> FAULTING_IP:
>>> nt!RtlFillMemoryUlong+10
>>> 82879100 f3ab rep stos dword ptr es:[edi]
>>>
>>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>>
>>> BUGCHECK_STR: 0xA
>>>
>>> PROCESS_NAME: System
>>>
>>> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
>>>
>>> TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
>>> ErrCode = 00000002
>>> eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8
>>> edi=96a9a000
>>> eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na
>>> pe nc
>>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>>> efl=00010206
>>> nt!RtlFillMemoryUlong+0x10:
>>> 82879100 f3ab rep stos dword ptr es:[edi]
>>> Resetting default scope
>>>
>>> LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0
>>>
>>> STACK_TEXT:
>>> 960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
>>> 96007724 828ebaab 8435bed0 00000040 00000000 nt!MiAddViewsForSection+0xa0
>>> 96007830 828eb300 85dc8990 84296d70 96007870
>>> nt!MmMapViewInSystemCache+0x28c
>>> 96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
>>> 960078e4 82aa968d 851f81d0 00000000 00000000 nt!CcGetVirtualAddress+0x1b1
>>> 9600792c 82a9f7bc 8435c2c0 00000000 00000000
>>> nt!CcMapAndCopyFromCache+0x53
>>> 96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
>>> 96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
>>> 96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
>>> 96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
>>> 96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
>>> 96007b1c 877803cb 96007b3c 847de940 00000000
>>> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
>>> 96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
>>> 96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
>>> 96007b8c 82a4c16e 847de940 8435c2c0 00000001
>>> nt!IopSynchronousServiceTail+0x1f8
>>> 96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
>>> 96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
>>> 96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
>>> 96007d08 8f80fd86 843a3d60 843c17d8 00000000 FileMount!ReadFile_RAW+0xf8
>>> [g:\project\cybercheck5\source
>>> code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
>>> 96007d50 82a2ed16 84268ed8 424c0e81 00000000
>>> FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source
>>> code\virtualmount\filemount\filemount\workerthread.c @ 49]
>>> 96007d90 828d0159 8f80fc90 84268ed8 00000000
>>> nt!PspSystemThreadStartup+0x9e
>>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
>>>
>>> — NTDEV is sponsored by OSR Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Bercea. G.

yes, I did’t realize that acquiring a spin lock raises the IRQL

On Fri, Sep 12, 2014 at 2:10 PM, Gabriel Bercea wrote:

> Well, don’t!
> Why do you keep a spin lock during this operation. Read the documentation
> of ZwReadFile and what keeping a spin lock does.
> A spinlock raises to DPC. Read your data and then do the synchronization.
> Why do you synch with spinlock in the first place ?
>
> Gabriel.
>
>
> On Fri, Sep 12, 2014 at 10:25 AM, Lloyd wrote:
>
>> Thank you Doron,
>>
>> Now I reread the KeAcquireSpinLock documentation, and understood the
>> reason.
>>
>> Thanks a lot,
>> Lloyd
>>
>>
>> On Fri, Sep 12, 2014 at 1:52 PM, Lloyd wrote:
>>
>>> Yes, I am acquiring a spinlock using KeAcquireSpinLock.
>>>
>>> Thanks,
>>> Lloyd
>>>
>>> On Fri, Sep 12, 2014 at 12:33 PM, Doron Holan >>> > wrote:
>>>
>>>> Are you holding a spinlock when you make the read call?
>>>>
>>>> d
>>>>
>>>> Bent from my phone
>>>> ------------------------------
>>>> From: Lloyd
>>>> Sent: ‎9/‎11/‎2014 11:56 PM
>>>> To: Windows System Software Devs Interest List
>>>> Subject: [ntdev] zwReadFile crashes
>>>>
>>>> Hi,
>>>>
>>>> I have created a worker thread using “PsCreateSystemThread”. inside
>>>> this thread I am opening a file handle using zwOpenFile and it opens the
>>>> file successfully. Then I have allocated 1024 bytes of memory from paged
>>>> pool using “ExAllocatePoolWithTag”. Then I have called zwReadFile to read
>>>> 512 bytes from the file. It causes a system crash. I have also tried
>>>> allocating the memory from non-paged pool, but that also did not work.
>>>>
>>>> I have read the bug-check analysis in WinDbg, it is showing Current
>>>> IRQL as 2. Isn’t the worker thread would be running at IRQL PASSIVE_LEVEL
>>>> always? What could be the reason for the crash?
>>>>
>>>> Thanks a lot,
>>>> Lloyd
>>>>
>>>>
>>>> This is what WinDbg shows :-
>>>>
>>>> BugCheck A, {96a9a000, 2, 1, 82879100}
>>>>
>>>> Probably caused by : memory_corruption
>>>>
>>>>
>>>> nt!RtlpBreakWithStatusInstruction:
>>>> 8289fbc0 cc int 3
>>>> kd> !analyze -v
>>>>
>>>> *****
>>>>
>>>>
>>>> * Bugcheck Analysis
>>>>
>>>>
>>>>
>>>>
>>>>

>>>>
>>>> IRQL_NOT_LESS_OR_EQUAL (a)
>>>> 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 a kernel debugger is available get the stack backtrace.
>>>> Arguments:
>>>> Arg1: 96a9a000, memory referenced
>>>> Arg2: 00000002, IRQL
>>>> Arg3: 00000001, bitfield :
>>>> bit 0 : value 0 = read operation, 1 = write operation
>>>> bit 3 : value 0 = not an execute operation, 1 = execute operation (only
>>>> on chips which support this level of status)
>>>> Arg4: 82879100, address which referenced memory
>>>>
>>>> Debugging Details:
>>>> ------------------
>>>>
>>>>
>>>> OVERLAPPED_MODULE: Address regions for ‘storport’ and ‘USBD.SYS’
>>>> overlap
>>>>
>>>> WRITE_ADDRESS: 96a9a000 Paged pool
>>>>
>>>> CURRENT_IRQL: 2
>>>>
>>>> FAULTING_IP:
>>>> nt!RtlFillMemoryUlong+10
>>>> 82879100 f3ab rep stos dword ptr es:[edi]
>>>>
>>>> DEFAULT_BUCKET_ID: CODE_CORRUPTION
>>>>
>>>> BUGCHECK_STR: 0xA
>>>>
>>>> PROCESS_NAME: System
>>>>
>>>> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
>>>>
>>>> TRAP_FRAME: 96007680 – (.trap 0xffffffff96007680)
>>>> ErrCode = 00000002
>>>> eax=8435bed2 ebx=8435bed0 ecx=00002000 edx=00002615 esi=8435bea8
>>>> edi=96a9a000
>>>> eip=82879100 esp=960076f4 ebp=96007724 iopl=0 nv up ei pl nz na
>>>> pe nc
>>>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>>>> efl=00010206
>>>> nt!RtlFillMemoryUlong+0x10:
>>>> 82879100 f3ab rep stos dword ptr es:[edi]
>>>> Resetting default scope
>>>>
>>>> LAST_CONTROL_TRANSFER: from 829186d5 to 8289fbc0
>>>>
>>>> STACK_TEXT:
>>>> 960076f4 828de33a 96a9a000 00008000 8435bed2 nt!RtlFillMemoryUlong+0x10
>>>> 96007724 828ebaab 8435bed0 00000040 00000000
>>>> nt!MiAddViewsForSection+0xa0
>>>> 96007830 828eb300 85dc8990 84296d70 96007870
>>>> nt!MmMapViewInSystemCache+0x28c
>>>> 96007890 828e0965 00000000 00000000 00000000 nt!CcGetVacbMiss+0x165
>>>> 960078e4 82aa968d 851f81d0 00000000 00000000
>>>> nt!CcGetVirtualAddress+0x1b1
>>>> 9600792c 82a9f7bc 8435c2c0 00000000 00000000
>>>> nt!CcMapAndCopyFromCache+0x53
>>>> 96007968 87828c8b 8435c2c0 960079ac 00000004 nt!CcCopyRead+0x107
>>>> 96007994 87826541 85059008 8435c2c0 8442e748 Ntfs!NtfsCachedRead+0x13e
>>>> 96007a70 87829bae 85059008 8442e748 1184807e Ntfs!NtfsCommonRead+0x11a1
>>>> 96007ae0 82875f44 84850020 8442e748 8442e748 Ntfs!NtfsFsdRead+0x279
>>>> 96007af8 8778020c 847de940 8442e748 00000000 nt!IofCallDriver+0x63
>>>> 96007b1c 877803cb 96007b3c 847de940 00000000
>>>> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
>>>> 96007b54 82875f44 847de940 8442e748 8442e748 fltmgr!FltpDispatch+0xc5
>>>> 96007b6c 82a4b287 8442e748 8442e8d8 8435c2c0 nt!IofCallDriver+0x63
>>>> 96007b8c 82a4c16e 847de940 8435c2c0 00000001
>>>> nt!IopSynchronousServiceTail+0x1f8
>>>> 96007c18 8287c79a 847de940 8442e748 00000000 nt!NtReadFile+0x644
>>>> 96007c18 8287b265 847de940 8442e748 00000000 nt!KiFastCallEntry+0x12a
>>>> 96007cb4 8f80ef38 80000848 00000000 00000000 nt!ZwReadFile+0x11
>>>> 96007d08 8f80fd86 843a3d60 843c17d8 00000000
>>>> FileMount!ReadFile_RAW+0xf8 [g:\project\cybercheck5\source
>>>> code\virtualmount\filemount\filemount\rawimagereader.c @ 95]
>>>> 96007d50 82a2ed16 84268ed8 424c0e81 00000000
>>>> FileMount!WorkerThreadStart+0xf6 [g:\project\cybercheck5\source
>>>> code\virtualmount\filemount\filemount\workerthread.c @ 49]
>>>> 96007d90 828d0159 8f80fc90 84268ed8 00000000
>>>> nt!PspSystemThreadStartup+0x9e
>>>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
>>>>
>>>> — NTDEV is sponsored by OSR Visit the list at:
>>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>>> other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>>> visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>
>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>
>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>> http://www.osr.com/seminars
>>>>
>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>
>>>
>>>
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
>> the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> Bercea. G.
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Oh my.

I guess we were all young once.

But still. You’ve GOT to understand something about the OS before you can competently undertake to extend that OS through the interface provided by the I/O Subsystem… and that’s precisely what you’re doing when you write a driver: Extending the OS.

Would you try to change how the engine in your car worked (let’s just cut this wire HERE, and attach a hose to THAT) without understanding the basics of how the engine worked?

Please don’t answer… that was a rhetorical question.

Peter
OSR
@OSRDrivers