problem in DispatchRead of filter driver

I have a file system filter driver and I have some problems with my dispatch read routine
As I read the read and write dispathces sould not be pageable.

this is the dispatch read:

NTSTATUS
SfRead (
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{

NTSTATUS Status;
PNAME_CONTROL fileName = NULL;
PSFILTER_DEVICE_EXTENSION devExt = (PSFILTER_DEVICE_EXTENSION)(DeviceObject->DeviceExtension);
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
BOOLEAN cacheName;
NAME_LOOKUP_FLAGS LookupFlags = 0x00000000;
//KEVENT waitEvent;
NTSTATUS localStatus,freeStatus;
UNICODE_STRING DosName;

if (IS_MY_CONTROL_DEVICE_OBJECT(DeviceObject)) {

Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
Irp->IoStatus.Information = 0;

IoCompleteRequest( Irp, IO_NO_INCREMENT );

return STATUS_INVALID_DEVICE_REQUEST;
}

ASSERT(IS_MY_DEVICE_OBJECT( DeviceObject ));

ASSERT(irpSp->MajorFunction != IRP_MJ_POWER);

Status = NLAllocateNameControl(
&fileName,
&gSfNameBufferLookasideList );

if (NT_SUCCESS( Status )) {

//
// We are okay not checking the return value here because
// the GetFullPathName function will set the Unicode String
// length to 0. So either way, in an error it will print an empty string
//

if (devExt->NLExtHeader.DosName.Length!=0)
SetFlag(LookupFlags,NLFL_USE_DOS_DEVICE_NAME);

localStatus = NLGetFullPathName(
irpSp->FileObject,
fileName,
&devExt->NLExtHeader,
LookupFlags,
&gSfNameBufferLookasideList,
&cacheName );

freeStatus=localStatus;

DosName.Buffer = ExAllocatePoolWithTag(
NonPagedPool,
255*sizeof(WCHAR),
‘dnb0’);

DosName.Length=0;
DosName.MaximumLength=255*sizeof(WCHAR);

__try
{

if (DosName.Buffer)
if (NT_SUCCESS(localStatus))
{

localStatus = GetDosNameFromDeviceNameAndFullNTPath(
&devExt->NLExtHeader.DeviceName,
&fileName->Name,
&DosName);

}

if (DosName.Buffer)
if (NT_SUCCESS(localStatus))
DbgPrint(“IRP_MJ_READ: FILE: DosName: %S\n”,DosName.Buffer);

}
__except(EXCEPTION_EXECUTE_HANDLER)
{
localStatus = GetExceptionCode();
DbgPrint(“Exception caught in sfread: 0x%x”,localStatus);
}

if (DosName.Buffer)
ExFreePoolWithTag(DosName.Buffer,‘dnb0’);

if (NT_SUCCESS(freeStatus))
NLFreeNameControl(fileName,&gSfNameBufferLookasideList);

}

IoSkipCurrentIrpStackLocation(Irp);

Status = IoCallDriver(
devExt->NLExtHeader.AttachedToDeviceObject,
Irp );

return Status;
}

NTSTATUS GetDosNameFromDeviceNameAndFullNTPath(
PUNICODE_STRING DeviceName,
PUNICODE_STRING FullNTPath,
PUNICODE_STRING DosName)
{

UNICODE_STRING VolumeDosName;
NTSTATUS Status;

// PAGED_CODE();

Status = GetDriveLetterFromDeviceName(
DeviceName,
&VolumeDosName);

if (!NT_SUCCESS(Status))
return Status;

if (DosName->MaximumLength< VolumeDosName.Length + (FullNTPath->Length-56))
{
ExFreePool(VolumeDosName.Buffer);
return STATUS_BUFFER_OVERFLOW;
}

RtlCopyMemory(
DosName->Buffer,
VolumeDosName.Buffer,
VolumeDosName.Length);

DosName->Length=VolumeDosName.Length;

ExFreePool(VolumeDosName.Buffer);

RtlAppendUnicodeToString(
DosName,
&FullNTPath->Buffer[23]);

return STATUS_SUCCESS;
}

NTSTATUS GetDriveLetterFromDeviceName(
PUNICODE_STRING DeviceName,
PUNICODE_STRING DriveLetter)

{
NTSTATUS Status;
PFILE_OBJECT VolumeFileObject;
PDEVICE_OBJECT VolumeDevice;

// PAGED_CODE();

Status=IoGetDeviceObjectPointer(DeviceName,
FILE_READ_ATTRIBUTES,
&VolumeFileObject,
&VolumeDevice);

if (!NT_SUCCESS(Status))
{
DbgPrint("Error get device pointer: 0x%x , Name: %S ",Status,DeviceName->Buffer);
return Status;
}

Status=IoVolumeDeviceToDosName(VolumeDevice,DriveLetter);
if (!NT_SUCCESS(Status))
{
DbgPrint(“Error volume device to dos name: 0x%x Name: %S”,Status, DeviceName->Buffer);
ObDereferenceObject(VolumeFileObject);

return Status;
}

ObDereferenceObject(VolumeFileObject);

return Status;
}

the problem is that I get blue screen. I have the same code for IRP_MJ_WRITE but it works OK.
How should I handle this. What is the issue I am missing.
Windbg says that the problem is improper addresing at IRQL = 2 (DISPATCH_LEVEL)
how do I control code execution at proper IRQL (< 2) , should I create a system thread and execute code there ?
please help .

Okay, I’ll bite on this one.

You “have some problems”? Is that the type of problem description you
expect from your customers? Tell me about your problems. Perhaps the
performance is not what you’d like? Perhaps your system is hung like an
Arabian stallion? Perhaps it causes an accvio in Ms-Word? Perhaps, just
perhaps, you got a blue screen? If so did you post the output of !analyze
-v, instead of pages and pages of crap code?

You understand that read and write must be non-pageable (for pagefile I/O).
If you take that to its logical conclusion, you’ll understand that you also
cannot call 37 pageable routines from your read dispatch. Furthermore, you
can’t get the filename in read–there’s locks, you know. Save it in create.

And it’s too late to write a legacy filter. Write a mini-filter.

And I just scrolled down past your 6 pages of crap code, and I see “the
problem is I get a blue screen.” Very helpful. Thank you very much. Start
debugging.

And, by the way, drive letters are totally meaningless in kernel mode. Time
to redesign.

And full paths can be a LOT longer than 255 characters. Time to rethink.

And this list has complete archives, where all your mistakes can be found.

Anyone else?

Good luck (you’ll need it),

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, July 17, 2007 6:56 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem in DispatchRead of filter driver

I have a file system filter driver and I have some problems with my dispatch
read routine As I read the read and write dispathces sould not be pageable.

this is the dispatch read:

NTSTATUS
SfRead (
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{

NTSTATUS Status;
PNAME_CONTROL fileName = NULL;
PSFILTER_DEVICE_EXTENSION devExt =
(PSFILTER_DEVICE_EXTENSION)(DeviceObject->DeviceExtension);
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
BOOLEAN cacheName;
NAME_LOOKUP_FLAGS LookupFlags = 0x00000000;
//KEVENT waitEvent;
NTSTATUS localStatus,freeStatus;
UNICODE_STRING DosName;

if (IS_MY_CONTROL_DEVICE_OBJECT(DeviceObject)) {

Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;
Irp->IoStatus.Information = 0;

IoCompleteRequest( Irp, IO_NO_INCREMENT );

return STATUS_INVALID_DEVICE_REQUEST;
}

ASSERT(IS_MY_DEVICE_OBJECT( DeviceObject ));

ASSERT(irpSp->MajorFunction != IRP_MJ_POWER);

Status = NLAllocateNameControl(
&fileName,
&gSfNameBufferLookasideList );

if (NT_SUCCESS( Status )) {

//
// We are okay not checking the return value here because
// the GetFullPathName function will set the Unicode String
// length to 0. So either way, in an error it will print an
empty string
//

if (devExt->NLExtHeader.DosName.Length!=0)

SetFlag(LookupFlags,NLFL_USE_DOS_DEVICE_NAME);

localStatus = NLGetFullPathName(
irpSp->FileObject,
fileName,
&devExt->NLExtHeader,
LookupFlags,
&gSfNameBufferLookasideList,
&cacheName );

freeStatus=localStatus;

DosName.Buffer = ExAllocatePoolWithTag(
NonPagedPool,
255*sizeof(WCHAR),
‘dnb0’);

DosName.Length=0;
DosName.MaximumLength=255*sizeof(WCHAR);

__try
{

if (DosName.Buffer)
if (NT_SUCCESS(localStatus))
{

localStatus =
GetDosNameFromDeviceNameAndFullNTPath(
&devExt->NLExtHeader.DeviceName,
&fileName->Name,
&DosName);

}

if (DosName.Buffer)
if (NT_SUCCESS(localStatus))
DbgPrint(“IRP_MJ_READ: FILE:
DosName: %S\n”,DosName.Buffer);

}
__except(EXCEPTION_EXECUTE_HANDLER)
{
localStatus = GetExceptionCode();
DbgPrint(“Exception caught in sfread: 0x%x”,localStatus);
}

if (DosName.Buffer)
ExFreePoolWithTag(DosName.Buffer,‘dnb0’);

if (NT_SUCCESS(freeStatus))
NLFreeNameControl(fileName,&gSfNameBufferLookasideList);

}

IoSkipCurrentIrpStackLocation(Irp);

Status = IoCallDriver(
devExt->NLExtHeader.AttachedToDeviceObject,
Irp );

return Status;
}

NTSTATUS GetDosNameFromDeviceNameAndFullNTPath(
PUNICODE_STRING DeviceName,
PUNICODE_STRING FullNTPath,
PUNICODE_STRING DosName)
{

UNICODE_STRING VolumeDosName;
NTSTATUS Status;

// PAGED_CODE();

Status = GetDriveLetterFromDeviceName(
DeviceName,
&VolumeDosName);

if (!NT_SUCCESS(Status))
return Status;

if (DosName->MaximumLength< VolumeDosName.Length +
(FullNTPath->Length-56))
{
ExFreePool(VolumeDosName.Buffer);
return STATUS_BUFFER_OVERFLOW;
}

RtlCopyMemory(
DosName->Buffer,
VolumeDosName.Buffer,
VolumeDosName.Length);

DosName->Length=VolumeDosName.Length;

ExFreePool(VolumeDosName.Buffer);

RtlAppendUnicodeToString(
DosName,
&FullNTPath->Buffer[23]);

return STATUS_SUCCESS;
}

NTSTATUS GetDriveLetterFromDeviceName(
PUNICODE_STRING DeviceName,
PUNICODE_STRING DriveLetter)

{
NTSTATUS Status;
PFILE_OBJECT VolumeFileObject;
PDEVICE_OBJECT VolumeDevice;

// PAGED_CODE();

Status=IoGetDeviceObjectPointer(DeviceName,

FILE_READ_ATTRIBUTES,

&VolumeFileObject,

&VolumeDevice);

if (!NT_SUCCESS(Status))
{
DbgPrint("Error get device pointer: 0x%x , Name: %S
",Status,DeviceName->Buffer);
return Status;
}

Status=IoVolumeDeviceToDosName(VolumeDevice,DriveLetter);
if (!NT_SUCCESS(Status))
{
DbgPrint(“Error volume device to dos name: 0x%x Name:
%S”,Status, DeviceName->Buffer);
ObDereferenceObject(VolumeFileObject);

return Status;
}

ObDereferenceObject(VolumeFileObject);

return Status;
}

the problem is that I get blue screen. I have the same code for IRP_MJ_WRITE
but it works OK. How should I handle this. What is the issue I am missing.
Windbg says that the problem is improper addresing at IRQL = 2
(DISPATCH_LEVEL)
how do I control code execution at proper IRQL (< 2) , should I create a
system thread and execute code there ? please help .


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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: 00001016, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e469a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00001016

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeSetEvent+30
804e469a 66394616 cmp [esi+0x16],ax

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 8057363a to 805e2513

IRP_ADDRESS: ffb04a60

DEVICE_OBJECT: 8123c8f8

DRIVER_OBJECT: 81295940

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: fc43d000 ftdisk

TRAP_FRAME: f8a17870 – (.trap fffffffff8a17870)
ErrCode = 00000000
eax=00000001 ebx=ffb04a01 ecx=f8a17680 edx=00000000 esi=00001000 edi=30303030
eip=804e469a esp=f8a178e4 ebp=f8a178f0 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!KeSetEvent+0x30:
804e469a 66394616 cmp [esi+0x16],ax ds:0023:00001016=???
Resetting default scope

STACK_TEXT:
f8a17c20 8057363a 81264de0 00000001 00000002 nt!FsRtlAcquireFileExclusiveCommon+0x1cd
f8a17c34 804f3913 81264de0 00000002 00000000 nt!FsRtlAcquireToCreateMappedSection+0x12
f8a17cd0 805644ed f8a17d1c 00000004 00000000 nt!MmCreateSection+0x265
f8a17d40 804de7ec 0007ef84 00000004 00000000 nt!NtCreateSection+0x12f
f8a17d40 7c90eb94 0007ef84 00000004 00000000 nt!KiFastCallEntry+0xf8
0007ee44 7c90d79f 7c815c2b 0007ef84 00000004 ntdll!KiFastSystemCallRet
0007ee48 7c815c2b 0007ef84 00000004 00000000 ntdll!ZwCreateSection+0xc
0007f254 7c8157f0 00000000 0007f2c0 0007f2ec kernel32!BasepCreateActCtx+0x3d0
0007f554 7ca27175 0007f560 00000020 00000008 kernel32!CreateActCtxW+0x6ef
0007f78c 7ca270f7 0007f7a0 0000007c 00000001 SHELL32!SHFusionInitializeIDCC+0x82
0007f9ac 7ca27035 7c9c0000 0000007c 00000001 SHELL32!SHFusionInitializeFromModuleID+0x3a
0007f9c0 7ca26ff2 7c9c0000 00000001 0007f9f0 SHELL32!_ProcessAttach+0x34
0007f9d0 7c9e736e 7c9c0000 00000001 0007fd30 SHELL32!DllMain+0x27
0007f9f0 7c9011a7 7c9c0000 00000001 0007fd30 SHELL32!_DllMainCRTStartup+0x52
0007fa10 7c91cbab 7c9e7326 7c9c0000 00000001 ntdll!LdrpCallInitRoutine+0x14
0007fb18 7c92173e 0007fd30 7ffdf000 7ffdd000 ntdll!LdrpRunInitializeRoutines+0x344
0007fc94 7c921639 0007fd30 7c900000 0007fce0 ntdll!LdrpInitializeProcess+0x1131
0007fd1c 7c90eac7 0007fd30 7c900000 00000000 ntdll!_LdrpInitialize+0x183
00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
804d8fd7 - nt!KiXMMIZeroPage+73
[fb:90]
804d8fdd-804d8fe0 4 bytes - nt!KiXMMIZeroPage+79 (+0x06)
[5c ff ff ff:2b 3f c1 00]
804d93b6-804d93ba 5 bytes - nt!ExAcquireResourceSharedLite+10 (+0x3d9)
[fa 8b 75 08 33:e9 d4 6c c9 00]
804de773-804de779 7 bytes - nt!KiFastCallEntry+7f (+0x53bd)
[c7 45 08 00 0d db ba:e9 ad e7 c0 00 cc cc]
804de7fd-804de800 4 bytes - nt!KiServiceExit (+0x8a)
[fa f7 45 70:e9 a8 18 c9]
804de8eb-804de8ed 3 bytes - nt!KiSystemCallExitBranch+2 (+0xee)
[5a 59 9d:c8 02 04]
804df05c-804df05f 4 bytes - nt!Kei386EoiHelper (+0x771)
[fa f7 45 70:e9 7c 10 c9]
804e16f0-804e16f5 6 bytes - nt!KiTrap0E+a4 (+0x2694)
[fb f7 45 70 00 02:90 e9 04 ea c8 00]
804e35db-804e35de 4 bytes - nt!ExAcquireResourceExclusiveLite+7 (+0x1eeb)
[64 a1 24 01:e9 74 ca c8]
804e35fe-804e3602 5 bytes - nt!ExAcquireResourceExclusiveLite+47 (+0x23)
[89 46 1c 66 89:e9 6f ca c8 00]
804e8a0d-804e8a12 6 bytes - nt!ExAcquireSharedWaitForExclusive+10 (+0x540f)
[fa 8b 75 08 33 db:e9 04 45 c0 00 cc]
804e8a2c - nt!ExAcquireSharedWaitForExclusive+ae (+0x1f)
[fb:90]
804e8a31-804e8a38 8 bytes - nt!ExAcquireSharedWaitForExclusive+ef (+0x05)
[c2 08 00 90 90 90 90 90:0f c7 c8 02 03 c2 08 00]
804ec75e-804ec764 7 bytes - nt!CcGetActiveVacb+5 (+0x3d2d)
[fa 8b 45 08 8b 48 48:e9 f1 07 c0 00 cc cc]
804ee12c-804ee133 8 bytes - nt!CcSetActiveVacb+7 (+0x19ce)
[fa 8b 45 08 83 78 48 00:e9 78 ee bf 00 cc cc cc]
804ee14f-804ee15c 14 bytes - nt!CcSetActiveVacb+a3 (+0x23)
[8b 0a 89 48 48 89 58 50:e9 45 ee bf 00 e9 34 ee]
87 errors : !nt (804d8fd7-804ee15c)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

MEMORY_CORRUPTOR: LARGE

STACK_COMMAND: .trap fffffffff8a17870 ; kb

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE

BUCKET_ID: MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

I can’t say that I know much of anything of file system filters, but
you’ve got a number of what look to be problems here. The first thing
is that the stack trace doesn’t include anything in the call stack other
than system functions, so it is not going to be directly of much use in
tracking down what you did. The address referenced, 0x00001016,
certainly looks bogus, but whether it is valid in the current context or
not, it certainly is not advisable to be referencing it at IRQL 2 unless
you know that it has been locked down, as it’s only shot of being valid
is if it comes from the paged pool, from user mode.

Haven’t we been here before? That is, IRP_MJ_READ works but not
IRP_MJ_WRITE and vice versa? And then it changes again? Maybe that was
a different thread; I’m not sure. In either case, you’re calling a
number of functions that ought not be called at IRQL 2; if nothing else,
the DbgPrint with %S will probably cause a blue screen unless you get
lucky. It looks like you got this code from somewhere else; it doesn’t
look like it was meant to be called at IRQL 2. Are you sure that you’re
code is being called at IRQL 2?

I guess the place to start is issue a kv 0x32 the next time this happens
to get more frames in the stack trace, which will hopefully show your
code’s involvement, but you’ve got a lot of fundamental problems here,
and file system filters are not know for shallow learning curve.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Wednesday, July 18, 2007 05:03
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] problem in DispatchRead of filter driver

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: 00001016, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804e469a, address which referenced memory

Debugging Details:

READ_ADDRESS: 00001016

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeSetEvent+30
804e469a 66394616 cmp [esi+0x16],ax

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 8057363a to 805e2513

IRP_ADDRESS: ffb04a60

DEVICE_OBJECT: 8123c8f8

DRIVER_OBJECT: 81295940

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: fc43d000 ftdisk

TRAP_FRAME: f8a17870 – (.trap fffffffff8a17870)
ErrCode = 00000000
eax=00000001 ebx=ffb04a01 ecx=f8a17680 edx=00000000 esi=00001000
edi=30303030
eip=804e469a esp=f8a178e4 ebp=f8a178f0 iopl=0 nv up ei pl nz na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010202
nt!KeSetEvent+0x30:
804e469a 66394616 cmp [esi+0x16],ax
ds:0023:00001016=???
Resetting default scope

STACK_TEXT:
f8a17c20 8057363a 81264de0 00000001 00000002
nt!FsRtlAcquireFileExclusiveCommon+0x1cd
f8a17c34 804f3913 81264de0 00000002 00000000
nt!FsRtlAcquireToCreateMappedSection+0x12
f8a17cd0 805644ed f8a17d1c 00000004 00000000 nt!MmCreateSection+0x265
f8a17d40 804de7ec 0007ef84 00000004 00000000 nt!NtCreateSection+0x12f
f8a17d40 7c90eb94 0007ef84 00000004 00000000 nt!KiFastCallEntry+0xf8
0007ee44 7c90d79f 7c815c2b 0007ef84 00000004 ntdll!KiFastSystemCallRet
0007ee48 7c815c2b 0007ef84 00000004 00000000 ntdll!ZwCreateSection+0xc
0007f254 7c8157f0 00000000 0007f2c0 0007f2ec
kernel32!BasepCreateActCtx+0x3d0
0007f554 7ca27175 0007f560 00000020 00000008
kernel32!CreateActCtxW+0x6ef
0007f78c 7ca270f7 0007f7a0 0000007c 00000001
SHELL32!SHFusionInitializeIDCC+0x82
0007f9ac 7ca27035 7c9c0000 0000007c 00000001
SHELL32!SHFusionInitializeFromModuleID+0x3a
0007f9c0 7ca26ff2 7c9c0000 00000001 0007f9f0 SHELL32!_ProcessAttach+0x34
0007f9d0 7c9e736e 7c9c0000 00000001 0007fd30 SHELL32!DllMain+0x27
0007f9f0 7c9011a7 7c9c0000 00000001 0007fd30
SHELL32!_DllMainCRTStartup+0x52
0007fa10 7c91cbab 7c9e7326 7c9c0000 00000001
ntdll!LdrpCallInitRoutine+0x14
0007fb18 7c92173e 0007fd30 7ffdf000 7ffdd000
ntdll!LdrpRunInitializeRoutines+0x344
0007fc94 7c921639 0007fd30 7c900000 0007fce0
ntdll!LdrpInitializeProcess+0x1131
0007fd1c 7c90eac7 0007fd30 7c900000 00000000 ntdll!_LdrpInitialize+0x183
00000000 00000000 00000000 00000000 00000000
ntdll!KiUserApcDispatcher+0x7

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
804d8fd7 - nt!KiXMMIZeroPage+73
[fb:90]
804d8fdd-804d8fe0 4 bytes - nt!KiXMMIZeroPage+79 (+0x06)
[5c ff ff ff:2b 3f c1 00]
804d93b6-804d93ba 5 bytes - nt!ExAcquireResourceSharedLite+10
(+0x3d9)
[fa 8b 75 08 33:e9 d4 6c c9 00]
804de773-804de779 7 bytes - nt!KiFastCallEntry+7f (+0x53bd)
[c7 45 08 00 0d db ba:e9 ad e7 c0 00 cc cc]
804de7fd-804de800 4 bytes - nt!KiServiceExit (+0x8a)
[fa f7 45 70:e9 a8 18 c9]
804de8eb-804de8ed 3 bytes - nt!KiSystemCallExitBranch+2 (+0xee)
[5a 59 9d:c8 02 04]
804df05c-804df05f 4 bytes - nt!Kei386EoiHelper (+0x771)
[fa f7 45 70:e9 7c 10 c9]
804e16f0-804e16f5 6 bytes - nt!KiTrap0E+a4 (+0x2694)
[fb f7 45 70 00 02:90 e9 04 ea c8 00]
804e35db-804e35de 4 bytes - nt!ExAcquireResourceExclusiveLite+7
(+0x1eeb)
[64 a1 24 01:e9 74 ca c8]
804e35fe-804e3602 5 bytes - nt!ExAcquireResourceExclusiveLite+47
(+0x23)
[89 46 1c 66 89:e9 6f ca c8 00]
804e8a0d-804e8a12 6 bytes - nt!ExAcquireSharedWaitForExclusive+10
(+0x540f)
[fa 8b 75 08 33 db:e9 04 45 c0 00 cc]
804e8a2c - nt!ExAcquireSharedWaitForExclusive+ae (+0x1f)
[fb:90]
804e8a31-804e8a38 8 bytes - nt!ExAcquireSharedWaitForExclusive+ef
(+0x05)
[c2 08 00 90 90 90 90 90:0f c7 c8 02 03 c2 08 00]
804ec75e-804ec764 7 bytes - nt!CcGetActiveVacb+5 (+0x3d2d)
[fa 8b 45 08 8b 48 48:e9 f1 07 c0 00 cc cc]
804ee12c-804ee133 8 bytes - nt!CcSetActiveVacb+7 (+0x19ce)
[fa 8b 45 08 83 78 48 00:e9 78 ee bf 00 cc cc cc]
804ee14f-804ee15c 14 bytes - nt!CcSetActiveVacb+a3 (+0x23)
[8b 0a 89 48 48 89 58 50:e9 45 ee bf 00 e9 34 ee]
87 errors : !nt (804d8fd7-804ee15c)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

MEMORY_CORRUPTOR: LARGE

STACK_COMMAND: .trap fffffffff8a17870 ; kb

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE

BUCKET_ID: MEMORY_CORRUPTION_LARGE

Followup: memory_corruption


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com