ZwQueryInformationFile causes crash, but only in one case

Hi,

I try to determinate filesize with


InitializeObjectAttributes(&objAttr, uniName,
OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
NULL, NULL);

/** CRASH HERE, WHEN TRY TO CALL ZwQueryInformationFile **/
status = ZwQueryInformationFile(
handle,
&IoStatusBlock,
&FileInformation,
sizeof(FileStandardInformation),
FileStandardInformation
);
if (NT_SUCCESS(status))
size = (ULONG)FileInformation.EndOfFile.QuadPart;

Filehande is ok, and file is opened for reading

ntstatus = ZwOpenFile(&handle,
SYNCHRONIZE | FILE_GENERIC_READ,
&objAttr, &ioStatusBlock,
FILE_SHARE_READ,
FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_NONALERT | FILE_SEQUENTION_ONLY);

----> this works fine in 99,9% but, while windows 1 Update ist running (Win7 32 bit testet only at the moment) and wualtclt.exe (window update service) is updated itself it crashed when trying to get fileinformation! (but filehandle can be quired an file seems to be open)

I try reading on processNotificationCallback (when process is starting). MSDN says, its always run at IRQL == PASSIVE_LEVEL, but here bugcheck says CURRENT_IRQL == 2 ? how can that be? - and is this the problem?

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: b9bf9000, memory referenced
Arg2: 00000001, value 0 = read operation, 1 = write operation
Arg3: 84d635f1, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)

Debugging Details:

WRITE_ADDRESS: b9bf9000 Special pool

FAULTING_IP:
Ntfs!NtfsFillStandardInfo+bf
84d635f1 f3ab rep stos dword ptr es:[edi]

MM_INTERNAL_CODE: 0

IMAGE_NAME: sxguard.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5208d764

MODULE_NAME: sxguard

FAULTING_MODULE: 84cb5000 Ntfs

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD6

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 2

TRAP_FRAME: aba7ada4 – (.trap 0xffffffffaba7ada4)
ErrCode = 00000002
eax=00000000 ebx=b9bf8ff8 ecx=00000004 edx=00000000 esi=b43ded78 edi=b9bf9000
eip=84d635f1 esp=aba7ae18 ebp=aba7ae54 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
Ntfs!NtfsFillStandardInfo+0xbf:
84d635f1 f3ab rep stos dword ptr es:[edi]
Resetting default scope

LAST_CONTROL_TRANSFER: from 828eb083 to 82887110

STACK_TEXT:
aba7a8ec 828eb083 00000003 527cb575 00000065 nt!RtlpBreakWithStatusInstruction
aba7a93c 828ebb81 00000003 9bb229b8 00000004 nt!KiBugCheckDebugBreak+0x1c
aba7ad00 8289a41b 00000050 b9bf9000 00000001 nt!KeBugCheck2+0x68b
aba7ad8c 8284d3d8 00000001 b9bf9000 00000000 nt!MmAccessFault+0x106
aba7ad8c 84d635f1 00000001 b9bf9000 00000000 nt!KiTrap0E+0xdc
aba7ae54 84d64582 aba7af60 869d0858 b9bf8ff8 Ntfs!NtfsFillStandardInfo+0xbf
aba7ae74 84d4c205 aba7af60 869d0858 b43ded78 Ntfs!NtfsQueryStandardInfo+0x3e
aba7aee8 84d5a6b4 aba7af60 ba12ee28 2f6891a4 Ntfs!NtfsCommonQueryInformation+0x548
aba7af4c 84d5a7cb aba7af60 ba12ee28 00000001 Ntfs!NtfsFsdDispatchSwitch+0x17b
aba7b080 82b3d6c3 8a1c5020 ba12ee28 00000000 Ntfs!NtfsFsdDispatchWait+0x1c
aba7b0a4 8284354a 00000000 ba12ee28 8a1c5020 nt!IovCallDriver+0x258
aba7b0b8 84c7620c 8a1c4e60 ba12ee28 00000000 nt!IofCallDriver+0x1b
aba7b0dc 84c763cb aba7b0fc 8a1c4e60 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
aba7b114 82b3d6c3 8a1c4e60 ba12ee28 ba12ee28 fltmgr!FltpDispatch+0xc5
aba7b138 8284354a 00000000 00000000 8a1c4e60 nt!IovCallDriver+0x258
aba7b14c 82a63e53 527cae41 aba7b224 aba7b2b0 nt!IofCallDriver+0x1b
aba7b208 8284a1ea 01c87e04 aba7b32c 00a7b2dc nt!NtQueryInformationFile+0x779
aba7b208 82848971 01c87e04 aba7b32c 00a7b2dc nt!KiFastCallEntry+0x12a
aba7b294 85299b0d 800046b8 aba7b32c aba7b2dc nt!ZwQueryInformationFile+0x11
aba7b37c 852a2197 aba7bba0 aba7b3b4 aba7b3a8 sxguard!readFile+0x16d [d:\daten\development\reddfort\trunk\app-protect\app-protect\drivers\sxguard64\sxguard\filereader.c @ 130]
aba7b3b8 852a2c23 aba7b420 ba13afb8 aba7bba0 sxguard!checkFileHashShared+0x57 [d:\daten\development\reddfort\trunk\app-protect\app-protect\drivers\sxguard64\sxguard\sxguardshared.c @ 236]
aba7b428 85295cc6 a8d23350 000002a0 aba7b460 sxguard!CreateProcessNotifyShared+0x193 [d:\daten\development\reddfort\trunk\app-protect\app-protect\drivers\sxguard64\sxguard\sxguardshared.c @ 678]
aba7b43c 82a7476c a8d23350 000002a0 aba7b460 sxguard!CreateProcessNotify+0x16 [d:\daten\development\reddfort\trunk\app-protect\app-protect\drivers\sxguard64\sxguard\sxguard.c @ 739]
aba7b4f4 82a7c799 8eb25328 01d23350 aba7b550 nt!PspInsertThread+0x5c0
aba7bc00 8284a1ea 00d3ed98 00d3ed74 02000000 nt!NtCreateUserProcess+0x742
aba7bc00 778570b4 00d3ed98 00d3ed74 02000000 nt!KiFastCallEntry+0x12a
00d3ea58 77855784 76a9e5d5 00d3ed98 00d3ed74 ntdll!KiFastSystemCallRet
00d3ea5c 76a9e5d5 00d3ed98 00d3ed74 02000000 ntdll!ZwCreateUserProcess+0xc
00d3f0b8 76a858dc 00000ea4 00000000 00d3f194 kernel32!CreateProcessInternalW+0xe75
00d3f0f0 6ded57da 00000ea4 00000000 00d3f194 kernel32!CreateProcessAsUserW+0x2d
00d3f5a8 6ded5df7 00000001 6ddb80fc 00000000 wuaueng!CSusCbsSelfUpdateTimeoutEvent::Reset+0x18b
00d3f5dc 6ded7122 00000000 00c83eb8 00c83e60 wuaueng!CSusCbsSelfUpdate::CommonPostInstallationTasks+0x61
00d3f650 6ded7376 00c83c80 00c83c80 00000001 wuaueng!CSusCbsSelfUpdate::InitStatusFromRegistry+0x522
00d3f66c 6ddced61 00c83c80 00000000 00c83c80 wuaueng!CSusCbsSelfUpdate::Init+0x208
00d3f68c 6ddcaf0b 00000001 00c83c80 00000000 wuaueng!CSelfUpdateManager::Init+0x50
00d3f8ec 6ddcaf7f 00000001 00000002 00000000 wuaueng!CSusClientGlobal::Init+0x230
00d3f900 6ddca5ff 00000001 004068a8 00000000 wuaueng!CSusClientGlobal::StartSusClient+0x11
00d3f9a8 6ddca856 00000001 029e4d30 6ddc9a98 wuaueng!ServiceMain+0x195
00d3f9c0 00241499 00000001 029e4d30 00000000 wuaueng!WUServiceMain+0x17
00d3f9ec 770575a8 00000001 029e4d30 00000000 svchost!ServiceStarter+0x17a
00d3fa00 76aa3c45 029e4d20 00d3fa4c 778737f5 sechost!ScSvcctrlThreadA+0x21
00d3fa0c 778737f5 029e4d20 775caa37 00000000 kernel32!BaseThreadInitThunk+0xe
00d3fa4c 778737c8 77057587 029e4d20 00000000 ntdll!__RtlUserThreadStart+0x70
00d3fa64 00000000 77057587 029e4d20 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND: kb

FOLLOWUP_IP:
sxguard!readFile+16d [d:\daten\development\reddfort\trunk\app-protect\app-protect\drivers\sxguard64\sxguard\filereader.c @ 130]
85299b0d 898554ffffff mov dword ptr [ebp-0ACh],eax

FAULTING_SOURCE_CODE:
126: &IoStatusBlock,
127: &FileInformation,
128: sizeof(FileStandardInformation),
129: FileStandardInformation

130: );
131: }
132: except (SxExceptionFilter( GetExceptionInformation(), TRUE ))
133: {
134: status = -1;
135: DbgPrint(“crash when try getting fileinforamtion %ld %wZ\n”, GetExceptionCode(), uniFilename);

SYMBOL_STACK_INDEX: 13

SYMBOL_NAME: sxguard!readFile+16d

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: 0xD6_VRF_sxguard!readFile+16d

BUCKET_ID: 0xD6_VRF_sxguard!readFile+16d

Followup: MachineOwner

The 4th parameter looks wrong. Try sizeof(FILE_STANDARD_INFORMATION) instead of sizeof(FileStandardInformation). And how was FileInformation allocated/declared??

a) OK
b) FILE_STANDARD_INFORMATION FileInformation;

Cool. That looks fine so the 4th parameter was probably just a typo. Just replace it with either sizeof(FILE_STANDARD_INFORMATION) or sizeof(FileInformation) and you should be good.

y, thanks I think that was the fault It sould be sizeof(FileInformation)…