256KB is a “magic number” in Windows file systems, relating to the size
of a cache map. It cannot properly accommodate a file that the file
system reports as being one size that turns out to be larger -
particularly over these cache map size boundaries.
The debugger is suggesting that your system has experienced memory
corruption; I’ve not used chkimage before, but it seems pretty
straight-forward in terms of its diagnosis - I’d suggest reading up on
it in the debugger documentation.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of NTFSD NTDEV
Sent: Monday, February 14, 2005 1:42 AM
To: ntfsd redirect
Subject: RE: [ntfsd] BSOD when installing VM ware…
Thanks a lot TONY for your reply and advice !
I have some more update on the problem, the write fails when I try to
copy a file which is more than 256 KB of size. Even if the size of the
file is 1 byte more than 256 KB the write fails. But the explorer shows
the size of the original file( as if the file is copied correctly )…
I tried to compare checksums of the “original file” with the “copied
file” and found they are different. I tried with the text files and saw
the content ,after 256 KB is not written into the file , eventhough the
windows explorer shows the size as the size of the original file.
Do you have any advice on this towards resolving this problem…
Here is the details of the stack after fixing the symbols,
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: ffffffff, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804dd1dd, address which referenced memory
Debugging Details:
READ_ADDRESS: ffffffff
CURRENT_IRQL: 2
FAULTING_IP:
nt!KiWaitSatisfyAll+14
804dd1dd 8a10 mov dl,[eax]
DEFAULT_BUCKET_ID: CODE_CORRUPTION
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 804dd1a5 to 804dd1dd
TRAP_FRAME: f92cdae8 – (.trap fffffffff92cdae8)
ErrCode = 00000000
eax=ffffffff ebx=80544280 ecx=f92cdc58 edx=00000000 esi=80535c38
edi=00000000
eip=804dd1dd esp=f92cdb5c ebp=f92cdc58 iopl=0 nv up ei pl nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
nt!KiWaitSatisfyAll+0x14:
804dd1dd 8a10 mov dl,[eax]
Resetting default scope
STACK_TEXT:
f92cdb68 804dd1a5 ffffefff 00000001 00000000 nt!KiWaitSatisfyAll+0x14
f92cdba0 805633dc 00000000 80544180 00000000
nt!KeWaitForMultipleObjects+0x301
f92cdbf0 80629946 00000000 00000000 f92cdc38 nt!CmpFileWrite+0x1a0
f92cdc68 80627881 e1340b68 00000000 00000000 nt!HvWriteHive+0x208
f92cdc8c 80622298 e101a6c8 00000b3c f92cdcc0 nt!CmDumpKey+0x6f
f92cdcac 804d6e91 e1774770 00000b3c 00000004 nt!NtSaveKeyEx+0x96
f92cdcac 8050deb7 e1774770 00000b3c 00000004 nt!KiSystemService+0xc4
f92cdd30 80622263 00000da4 00000b3c 00000004 nt!ZwSaveKeyEx+0x11
f92cdd50 804d6e91 00000da4 00000b3c 00000004 nt!NtSaveKeyEx+0x61
f92cdd50 7ffe0304 00000da4 00000b3c 00000004 nt!KiSystemService+0xc4
00ddee00 77f7f0bf 77dde997 00000da4 00000b3c
SharedUserData!SystemCallStub+0x4
00ddee04 77dde997 00000da4 00000b3c 00000004 ntdll!ZwSaveKeyEx+0xc
00ddee58 77ddb40b 00000da4 00000b3c 00000000
ADVAPI32!LocalBaseRegSaveKeyEx+0xf8
00ddee9c 750f5a8c 00000da4 00ddeee4 00000000 ADVAPI32!RegSaveKeyExW+0x78
00ddeec4 750f7958 80000003 00000002 00ddeee4 srsvc!SaveRegKey+0xd2
00ddf1c0 750f79bb 00ddf20c 00000000 00000000
srsvc!ProcessHKUsersKey+0x267
00ddf1d4 750f8608 00ddf20c 0058d600 0016f4e0
srsvc!CSnapshot::DoRegistrySnapshot+0x11
00ddf420 750ebd50 00ddf444 6ffb0000 00ddf650
srsvc!CSnapshot::CreateSnapshot+0x3c0
00ddf8ec 750ee016 00000000 00ddfad0 77c72f58
srsvc!CEventHandler::SRSetRestorePointS+0x599
00ddf8f8 77c72f58 000e1900 0016f4e0 00ddfad0
srsvc!SRSetRestorePointS+0x17
00ddf918 77cd81a5 750edfff 00ddf92c 00000003 RPCRT4!Invoke+0x30
00ddfd00 77cd85d7 00000000 00000000 000e1a14 RPCRT4!NdrStubCall2+0x1fb
00ddfd1c 77c72dcf 000e1a14 00000000 000006bb RPCRT4!NdrServerCall2+0x17
00ddfd50 77c72d4c 750fba7e 000e1a14 00ddfdfc
RPCRT4!DispatchToStubInC+0x38
00ddfdac 77c72c56 000e1a14 00000000 75101a98
RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x132
00ddfdd0 77c754ee 000e1a14 00000000 75101a98
RPCRT4!RPC_INTERFACE::DispatchToStub+0x82
00ddfe08 77c7532a 00126820 80020000 000bda88
RPCRT4!LRPC_SCALL::DealWithRequestMessage+0x351
00ddfe2c 77c71b46 000c734c 00ddfe48 00126820
RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0x16b
00ddff90 77c7167e 77c71505 000c7310 00b3fd84
RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0x298
00ddff94 77c71505 000c7310 00b3fd84 77f82402
RPCRT4!RecvLotsaCallsWrapper+0x9
00ddffac 77c71670 00007530 77e402ed 000add30
RPCRT4!BaseCachedThreadRoutine+0x64
00ddffb4 77e402ed 000add30 00b3fd84 77f82402
RPCRT4!ThreadStartRoutine+0x16
00ddffec 00000000 77c7165a 000add30 00000000
kernel32!BaseThreadStart+0x37
CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
804d6e1f-804d6e23 5 bytes - nt!KiSystemService+52
[0f 85 c7 fe ff:e9 a3 32 46 00]
804d6ea2-804d6ea5 4 bytes - nt!KiServiceExit (+0x83)
[fa f7 45 70:e9 3c 32 46]
804d6f8f-804d6f93 5 bytes - nt!KiSystemCallExitBranch+2 (+0xed)
[5a 59 9d ff e2:e9 17 52 58 00]
804d76ba-804d76bd 4 bytes - nt!Kei386EoiHelper (+0x72b)
[fa f7 45 70:e9 41 2a 46]
804d9a33-804d9a38 6 bytes - nt!KiTrap0E+90 (+0x2379)
[fb f7 45 70 00 02:90 e9 e4 06 46 00]
804ebd3c-804ebd3f 4 bytes - nt!ExAcquireResourceExclusiveLite+5
(+0x12309)
[64 a1 24 01:e9 30 e3 44]
804ebd5d-804ebd61 5 bytes - nt!ExAcquireResourceExclusiveLite+45 (+0x21)
[89 46 1c 66 89:e9 2d e3 44 00]
804ebda3-804ebda7 5 bytes - nt!ExAcquireResourceSharedLite+f (+0x46)
[fa 8b 75 08 33:e9 04 e3 44 00]
804ec25d-804ec261 5 bytes - nt!ExReleaseResourceLite+d (+0x4ba)
[fa 8b 55 fc f6:e9 f2 dd 44 00]
804f1189-804f118d 5 bytes - nt!ExIsResourceAcquiredExclusiveLite+6
(+0x4f2c)
[fa 8b 4c 24 04:e9 26 91 44 00]
804f22e9-804f22ed 5 bytes - nt!KiRetireDpcList+2e (+0x1160)
[fb ff d1 fa 3b:e9 68 7f 44 00]
804f4da6-804f4daa 5 bytes - nt!CcGetActiveVacb+10 (+0x2abd)
[74 1e 8b 48 50:e9 8d 54 44 00]
804f4dc4-804f4dc8 5 bytes - nt!CcGetActiveVacb+2e (+0x1e)
[89 01 fb c2 10:e9 b9 54 44 00]
80511112-80511116 5 bytes - nt!KeUpdateSystemTime+114 (+0x1c34e)
[fa ff 15 dc 25:e9 39 90 42 00]
68 errors : !nt (804d6e1f-80511116)
MODULE_NAME: memory_corruption
IMAGE_NAME: memory_corruption
FOLLOWUP_NAME: memory_corruption
DEBUG_FLR_IMAGE_TIMESTAMP: 0
MEMORY_CORRUPTOR: LARGE
STACK_COMMAND: .trap fffffffff92cdae8 ; kb
FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE
BUCKET_ID: MEMORY_CORRUPTION_LARGE
Followup: memory_corruption
Tony Mason wrote:
The first step is to fix your debugging environment so it gives
you proper information. While cutting and pasting garbage (and then
sending it to NTFSD) is easy, it doesn’t achieve much.
Did you notice the message:
*****Kernel symbols are WRONG. Please fix symbols to do
analysis.
This line means that before anyone can use your dump to do
anything, you need to fix the symbols. Given that this is
straight-forward to do (assuming you are using a current version of the
debugger - and I suggest if you are not upgrading to 6.4.7.2 which is on
the MS web site - http://www.microsoft.com/whdc/ddk/debugging.) Fixing
symbols is as simple as typing “.symfix” (not the ONLY way, but the
easiest way). If you have symbols for your driver, you can also type
“.symfix+”. In either case, it will add the Microsoft symbol server to
your search path. Then do a “.reload” and “!analyze -v”. IF you
don’t see that warning message anymore, THEN it is ok to cut and paste
the output and send it to NTFSD.
The “information” you sent along is almost worthless - the only
thing we know from this is the bugcheck code and parameters, which means
“invalid pointer” and the pointer is “0xFFFFFFFF”. Since your IRQL is
>= DISPATCH_LEVEL this causes the OS to bugcheck, since page faults are
not allowed at DISPATCH_LEVEL. From that I can’t honestly hazard a
guess as to what you are doing wrong in your driver.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of NTFSD NTDEV
Sent: Sunday, February 06, 2005 7:10 AM
To: ntfsd redirect
Subject: [ntfsd] BSOD when installing VM ware…
I am developing my filter driver using sfilter sample from 2003
IFS kit
I am getting a BSOD when ever I try to install the VMWARE in my
machine…
When ever I am trying you doenload some files from internet
,those files are downloaded as corrupted…I could not run the Exes …
Without my filter driver the Vmware is getting installed
properly…
All the downloads are proper…
the details of my BSOD is below.
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: ffffffff, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804fe3a7, address which referenced memory
Debugging Details:
------------------
***** Kernel symbols are WRONG. Please fix symbols to do
analysis.
READ_ADDRESS: unable to get nt!MmPoolCodeEnd
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSpecialPoolStart
unable to get nt!MmPagedPoolStart
unable to get nt!MiSessionPoolStart
unable to get nt!MiSessionPoolEnd
unable to get nt!MmNonPagedPoolExpansionStart
unable to get nt!MmPoolCodeStart
ffffffff
CURRENT_IRQL: 2
FAULTING_IP:
nt!RtlNumberOfSetBits+1b0
804fe3a7 8a10 mov dl,[eax]
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 805353be to 804e5b25
STACK_TEXT:
WARNING: Stack unwind information not available. Following
frames may be wrong.
f473b6e0 805353be 00000003 ffffffff 804fe3a7
nt!DbgBreakPointWithStatus+0x4
f473bac0 804e4158 0000000a ffffffff 00000002
nt!KeDeregisterBugCheckReasonCallback+0x6c7
f473bae0 804fe3a7 badb0d00 00000000 00000000
nt!Kei386EoiHelper+0x285d
f473bb64 804fe362 ffffefff 00000001 00000000
nt!RtlNumberOfSetBits+0x1b0
f473bb9c 8059c312 00000000 80558e80 00000000
nt!RtlNumberOfSetBits+0x16b
f473bbec 80657f9b 00000000 00000000 f473bc14
nt!MmLockPagableDataSection+0x8ab
f473bc68 806558ac e1627728 00000000 00000000
nt!LsaDeregisterLogonProcess+0xcad0
80558f80 811f5b88 ffb63980 ffb84f98 80558f80
nt!LsaDeregisterLogonProcess+0xa3e1
811f5b88 811f5b88 1a070006 812b2020 00300012 0x811f5b88
FOLLOWUP_IP:
nt!RtlNumberOfSetBits+1b0
804fe3a7 8a10 mov dl,[eax]
SYMBOL_STACK_INDEX: 3
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!RtlNumberOfSetBits+1b0
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 41108004
STACK_COMMAND: kb
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
-------------------------------
I have been trying a lot to find out where the problem could be
…
The following is my write dispacth routine…
NTSTATUS
SECUREWriteDispatch (
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp )
{
/// this is the structure I am sharing between a usermode
service and my filter
SECURE_SHARE_DATA sharedata = {0,};
int present = 0 , i = 0;
PIO_STACK_LOCATION IrpSp = NULL;
UNICODE_STRING FullPathUni = {0,};
WCHAR FullPathBuff[MAX_DEVNAME_LENGTH];
ASSERT(!IS_MY_CONTROL_DEVICE_OBJECT( DeviceObject ));
ASSERT(IS_MY_DEVICE_OBJECT( DeviceObject ));
IrpSp = IoGetCurrentIrpStackLocation(Irp);
/// SECURERetrieveFileName gets the file name associated with
the fileobject …
// the filenames are stored in a global array thta has filename
-WCHAR , File object ,
// and filelength as members…
if( ! SECURERetrieveFileName(IrpSp->FileObject,FullPathBuff) )
{
return SECUREPassThrough(DeviceObject,Irp);
}
if( wcslen( FullPathBuff ) )
{
DbgPrint("\n ##### BEFORE RtlInitUnicodeString ");
RtlInitUnicodeString(&FullPathUni,FullPathBuff);
RtlStringCchCopyNW( sharedata.SECUREFileName ,
MAX_DEVNAME_LENGTH , FullPathUni.Buffer
,FullPathUni.Length / sizeof( WCHAR ) );
sharedata.SECUREProcessID = PsGetCurrentProcessId( );
sharedata.SECUREAccess = FALSE;
sharedata.SECUREirp = SECURE_WRITE_IRP; //
present = SECURESubString(&FullPathUni,&SecureGUI);
//// this will return the TRUE is the second parameter string
is present in the first
//// paramter string…
if( present )
{
//// SECURECheckAccess(&sharedata) will check the access from
usermode service …
//// I got to deny the access if no permission is from
usermode…
if( ! SECURECheckAccess(&sharedata) )
{
Irp->IoStatus.Status = STATUS_ACCESS_DENIED;
Irp->IoStatus.Information = 0;
IoCompleteRequest( Irp, IO_NO_INCREMENT );
return STATUS_ACCESS_DENIED;
}
}
else
{
}
}
DbgPrint( “\n\n( Before calling PASS THRU ((((((((((((((((
”);
return SECUREPassThrough(DeviceObject,Irp);
}
Is there anything wrong with my code. please help me if in
finding what could be the problem…
Thanks a lot in advance…
PRIYA MS
Do you Yahoo!?
Yahoo! Search presents - Jib Jab’s ‘Second Term’
http:/jibjabinaugural.html> — Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: xxxxx@osr.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
PRIYA MS
________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http:
— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: xxxxx@osr.com To unsubscribe send a blank email to
xxxxx@lists.osr.com</http:></http:>