I had a previous thread about the way to make a corect message for
IRP_MJ_READ, so if you read it u know that I am making a file system
filter driver based on the sfilter exmaple from the WDK from
Microsoft. For those who don't know sfilter, it attaches to all the
volume devices, and processes the IRP's as pass throughs.
The problem is that whenever I write some code in the driver entry,
except the existent code, code like calling a function or something it
has something to do with the code later on and I don't understand
why.
for example I have a function called
NTSTATUS GetFileObjectFromPathEx(
PDEVICE_OBJECT DeviceObject,
PUNICODE_STRING Path,
PFILE_OBJECT *FileObject,
PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess)
which give u the file object for a file by a given path, by sending
the request to a specific Device.

the thing is that when I call this function in my IRP_MJ_WRITE
dispatch routine the function works great, every time, I have no
problem using it. well when I call the funtion in driver entry, just
for testing I mean, the things change later on. In my IRP_MJ_WRITE I
need to get the file name for the current file and compare it I use
RtlCompareUnicodeString If I don't call GetFileObjectFromPathEx or
other functions made by me in driverentry, the comparing goes
smoothly, but if I call this function or any other function that calls
some api like: IoCreateFileSpecifyDeviceObjectHint or ZwCreateKey or
ZwQueryValueKey the code crashes in the RtlCompareUnicodeString If i
comment the rtlcompareunicodestring in my dispatch routines and also
call the functions in the driver entry everything goes smoothly. Why
does this happen. How should I make my initializations. . . I close
all the handles I open in the driverentry and dereference all objects
if I reference any, so I have no memory leaks that could affect in the
future. Please help, note that this is file system filter driver, and
the device is of this type: FILE_DEVICE_DISK_FILE_SYSTEM. thank you

Re: Strange error possibly because of code in driver entry by Mark

Mark
Sun Jul 15 16:20:12 CDT 2007

euacela@gmail.com wrote:
> I had a previous thread about the way to make a corect message for
> IRP_MJ_READ, so if you read it u know that I am making a file system
> filter driver based on the sfilter exmaple from the WDK from
> Microsoft. For those who don't know sfilter, it attaches to all the
> volume devices, and processes the IRP's as pass throughs.
> The problem is that whenever I write some code in the driver entry,
> except the existent code, code like calling a function or something it
> has something to do with the code later on and I don't understand
> why.
> for example I have a function called
> NTSTATUS GetFileObjectFromPathEx(
> PDEVICE_OBJECT DeviceObject,
> PUNICODE_STRING Path,
> PFILE_OBJECT *FileObject,
> PHANDLE FileHandle,
> IN ACCESS_MASK DesiredAccess)
> which give u the file object for a file by a given path, by sending
> the request to a specific Device.
>
> the thing is that when I call this function in my IRP_MJ_WRITE
> dispatch routine the function works great, every time, I have no
> problem using it. well when I call the funtion in driver entry, just
> for testing I mean, the things change later on. In my IRP_MJ_WRITE I
> need to get the file name for the current file and compare it I use
> RtlCompareUnicodeString If I don't call GetFileObjectFromPathEx or
> other functions made by me in driverentry, the comparing goes
> smoothly, but if I call this function or any other function that calls
> some api like: IoCreateFileSpecifyDeviceObjectHint or ZwCreateKey or
> ZwQueryValueKey the code crashes in the RtlCompareUnicodeString If i
> comment the rtlcompareunicodestring in my dispatch routines and also
> call the functions in the driver entry everything goes smoothly. Why
> does this happen. How should I make my initializations. . . I close
> all the handles I open in the driverentry and dereference all objects
> if I reference any, so I have no memory leaks that could affect in the
> future. Please help, note that this is file system filter driver, and
> the device is of this type: FILE_DEVICE_DISK_FILE_SYSTEM. thank you
>

It would help if you included the bugcheck information (from windbg
!analyze -v command) and also the actual code rather your description of
the code.

From your description I have no idea. Obviously you do have side
effects from your DriverEntry invocations of these functions.

--

=====================
Mark Roddy DDK MVP
Windows Vista/2003/XP Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Re: Strange error possibly because of code in driver entry by euacela

euacela
Sun Jul 15 18:57:53 CDT 2007

I hoe this helps

NTSTATUS GetBackUpFileNamesFromRegistry(
PUNICODE_STRING *FileNames,
PULONG NumberOfNames);

NTSTATUS FreeUnicodeStrings(
PUNICODE_STRING *FileNames,
ULONG NumberOfNames);


NTSTATUS GetBackUpFileNamesFromRegistry(
PUNICODE_STRING *FileNames,
PULONG NumberOfNames)
{
NTSTATUS Status;
HANDLE hKey;
OBJECT_ATTRIBUTES ObjAttr;
UNICODE_STRING RegPath;
ULONG Disposition,BufferLength,ret,cnt;
PKEY_VALUE_PARTIAL_INFORMATION KeyInfo;




*NumberOfNames = 10;



try
{
if (!MmIsAddressValid(FileNames))
return STATUS_ACCESS_VIOLATION;
}
except(EXCEPTION_EXECUTE_HANDLER)
{
return STATUS_ACCESS_VIOLATION;
}

RtlInitUnicodeString(
&RegPath,
L"\\Registry\\Machine\\Software\\BackupXP");


InitializeObjectAttributes(
&ObjAttr,
&RegPath,
OBJ_CASE_INSENSITIVE,
NULL,
NULL);

Status = ZwCreateKey(
&hKey,
KEY_READ|KEY_QUERY_VALUE|KEY_ENUMERATE_SUB_KEYS,
&ObjAttr,
0,
NULL,
REG_OPTION_NON_VOLATILE,
&Disposition);

if (!NT_SUCCESS(Status))
{
*FileNames = NULL;
NumberOfNames = 0;
return Status;
}

if (Disposition == REG_CREATED_NEW_KEY)
{
*FileNames = NULL;
NumberOfNames = 0;
return Status;
}

BufferLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION)
+256*sizeof(WCHAR);

KeyInfo=ExAllocatePoolWithTag(
NonPagedPool,
BufferLength,
'knm');

if (!KeyInfo)
{
ZwClose(hKey);
*FileNames = NULL;
NumberOfNames = 0;
return STATUS_INSUFFICIENT_RESOURCES;
}

RtlZeroMemory(
KeyInfo,
BufferLength);


*FileNames = ExAllocatePoolWithTag(
NonPagedPool,
10*sizeof(UNICODE_STRING),
'fni');

if (!KeyInfo)
{
ZwClose(hKey);
*FileNames = NULL;
NumberOfNames = 0;
return STATUS_INSUFFICIENT_RESOURCES;
}

cnt = 0;

try
{


while
((Status=ZwEnumerateValueKey(hKey,cnt,KeyValuePartialInformation,KeyInfo,BufferLength,&ret))!
=STATUS_NO_MORE_ENTRIES)
{

if (cnt>=10)
break;

if (Status == STATUS_INFO_LENGTH_MISMATCH)
{
ExFreePoolWithTag(KeyInfo,'knm');
BufferLength = BufferLength*2;
KeyInfo=ExAllocatePoolWithTag(
NonPagedPool,
BufferLength,
'knm');

}

if (NT_SUCCESS(Status))
{


FileNames[0][cnt].Buffer = ExAllocatePoolWithTag(
NonPagedPool,
KeyInfo->DataLength,
'unm');

if (!FileNames[0][cnt].Buffer)
{
ZwClose(hKey);
*NumberOfNames = cnt + 1;
return STATUS_INSUFFICIENT_RESOURCES;

}

RtlCopyMemory(FileNames[0][cnt].Buffer,KeyInfo->Data,KeyInfo-
>DataLength);
FileNames[0][cnt].Length=(USHORT)KeyInfo->DataLength;
FileNames[0][cnt].MaximumLength=FileNames[0][cnt].Length;

DbgPrint("Nume primit: %S\n",FileNames[0][cnt].Buffer);
cnt++;
}
else if (Status !=STATUS_INFO_LENGTH_MISMATCH)
break;


}

}
except(EXCEPTION_EXECUTE_HANDLER)
{
Status=GetExceptionCode();
DbgPrint("Exception raised: 0x%x",Status);
ZwClose(hKey);
if (KeyInfo)
ExFreePoolWithTag(KeyInfo,'knm');
*NumberOfNames = cnt + 1;
return Status;
}



ZwClose(hKey);
ExFreePoolWithTag(
KeyInfo,
'knm');

if (NT_SUCCESS(Status))
*NumberOfNames = cnt;
else
*NumberOfNames = 0;


return Status;
}

NTSTATUS FreeUnicodeStrings(
PUNICODE_STRING *FileNames,
ULONG NumberOfNames)
{
ULONG cnt;


for (cnt=0; cnt<NumberOfNames; cnt++)
ExFreePoolWithTag(FileNames[0][cnt].Buffer,'unm');


ExFreePoolWithTag(*FileNames,'fni');

return STATUS_SUCCESS;
}



and now the analyze from windbg
it is kind of problematic because I have some problems with the
symbols


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

Use !analyze -v to get detailed debugging information.

BugCheck 50, {f888a490, 0, 8056c057, 0}

Probably caused by : sfilter.sys ( sfilter!SfWrite+1eb )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

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: f888a490, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8056c057, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000000, (reserved)

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


READ_ADDRESS: f888a490

FAULTING_IP:
nt!RtlCompareUnicodeString+46
8056c057 668b3a mov di,[edx]

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from f88842eb to 8056c057

TRAP_FRAME: fc8e79d4 -- (.trap fffffffffc8e79d4)
ErrCode = 00000000
eax=e10b34d8 ebx=81262660 ecx=c1062004 edx=f888a490 esi=e10b3498
edi=8117f758
eip=8056c057 esp=fc8e7a48 ebp=fc8e7a60 iopl=0 nv up ei ng nz
na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
nt!RtlCompareUnicodeString+0x46:
8056c057 668b3a mov di,[edx] ds:
0023:f888a490=????
Resetting default scope

STACK_TEXT:
fc8e7a60 f88842eb e10b3488 f8883980 00000001 nt!RtlCompareUnicodeString
+0x46
fc8e7b24 804e37f7 81262660 81187a98 00000000 sfilter!SfWrite+0x1eb [c:
\winddk\6000\src\filesys\filter\file_system_filter\sfilter.c @ 2311]
fc8e7b34 804eeadd fc8e7b70 fc8e7d40 00000000 nt!IopfCallDriver+0x31
fc8e7b48 804ee6a6 8117f70a fc8e7b70 fc8e7c04 nt!IoSynchronousPageWrite
+0xaf
fc8e7c24 804ed331 e14c2008 e14c200c e14c200c nt!MiFlushSectionInternal
+0x38b
fc8e7c60 804eed68 812500b0 e14c2008 00000000 nt!MmFlushSection+0x1b5
fc8e7ce8 804ed178 00001000 00000000 00000001 nt!CcFlushCache+0x372
fc8e7d2c 804e4f1d 812911e8 80561440 8128eb30 nt!CcWriteBehind+0xdc
fc8e7d74 804e426b 812911e8 00000000 8128eb30 nt!CcWorkerThread+0x126
fc8e7dac 8057be15 812911e8 00000000 00000000 nt!ExpWorkerThread+0x100
fc8e7ddc 804fa4da 804e4196 00000000 00000000 nt!PspSystemThreadStartup
+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
sfilter!SfWrite+1eb [c:\winddk\6000\src\filesys\filter
\file_system_filter\sfilter.c @ 2311]
f88842eb 85c0 test eax,eax

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: sfilter!SfWrite+1eb

MODULE_NAME: sfilter

IMAGE_NAME: sfilter.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 469ab2f9

STACK_COMMAND: .trap fffffffffc8e79d4 ; kb

FAILURE_BUCKET_ID: 0x50_sfilter!SfWrite+1eb

BUCKET_ID: 0x50_sfilter!SfWrite+1eb

Followup: MachineOwner
---------



> It would help if you included the bugcheck information (from windbg
> !analyze -v command) and also the actual code rather your description of
> the code.
>
> From your description I have no idea. Obviously you do have side
> effects from your DriverEntry invocations of these functions.
>
> --
>
> =====================
> Mark Roddy DDK MVP
> Windows Vista/2003/XP Consulting
> Hollis Technology Solutions 603-321-1032www.hollistech.com



Re: Strange error possibly because of code in driver entry by David

David
Sun Jul 15 20:48:11 CDT 2007

Have you stepped through the code with windbg looking at each line and the
results as it executes? Try using the non-source mode so you see each
instruction execute and watch the target address to see if you have an
error. An address can be valid but wrong and create overwrites in bad
places.

First, I would never allow a pointer to an array where the callee allocates
the array to be other than NULL when the callee obtains control. You should
check *FileNames and if not NULL return STATUS_INVALID_PARAMETER as this
makes it too easy for the caller to cause memory leaks.

The assignment of zero to NumberOfNames is a bad idea. You need the '*'
prefix to indicate the ULONG and not nulling out the pointer. Set it to
zero at the beginning of your routine and you can increment it as you find
the keys. Also you only assume that ZwEnumerateValueKey can return
STATUS_NO_MORE_ENTRIES, but the documentation shows four returns and doesn't
exclude there being more than those four.

Do you need to create the keys or must they be present? Will they need to
be read in a boot driver? The 'software' keys are not available until much
later. I would use ZwOpenKey instead of ZwCreateKey.

Why are you using MmIsAddressValid? It serves no purpose that I can see and
can fail as the WDK indicates it can return TRUE, but later access can
produce a fault.

Is the registry key unique to your product or a standard software key? If
unique, put it under your product's or company's name.

I skipped a lot of the code and do have my doubts about it, but the above
should get you started.

--
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation


<euacela@gmail.com> wrote in message
news:1184543873.031672.132340@g4g2000hsf.googlegroups.com...
>I hoe this helps
>
> NTSTATUS GetBackUpFileNamesFromRegistry(
> PUNICODE_STRING *FileNames,
> PULONG NumberOfNames);
>
> NTSTATUS FreeUnicodeStrings(
> PUNICODE_STRING *FileNames,
> ULONG NumberOfNames);
>
>
> NTSTATUS GetBackUpFileNamesFromRegistry(
> PUNICODE_STRING *FileNames,
> PULONG NumberOfNames)
> {
> NTSTATUS Status;
> HANDLE hKey;
> OBJECT_ATTRIBUTES ObjAttr;
> UNICODE_STRING RegPath;
> ULONG Disposition,BufferLength,ret,cnt;
> PKEY_VALUE_PARTIAL_INFORMATION KeyInfo;
>
>
>
>
> *NumberOfNames = 10;
>
>
>
> try
> {
> if (!MmIsAddressValid(FileNames))
> return STATUS_ACCESS_VIOLATION;
> }
> except(EXCEPTION_EXECUTE_HANDLER)
> {
> return STATUS_ACCESS_VIOLATION;
> }
>
> RtlInitUnicodeString(
> &RegPath,
> L"\\Registry\\Machine\\Software\\BackupXP");
>
>
> InitializeObjectAttributes(
> &ObjAttr,
> &RegPath,
> OBJ_CASE_INSENSITIVE,
> NULL,
> NULL);
>
> Status = ZwCreateKey(
> &hKey,
> KEY_READ|KEY_QUERY_VALUE|KEY_ENUMERATE_SUB_KEYS,
> &ObjAttr,
> 0,
> NULL,
> REG_OPTION_NON_VOLATILE,
> &Disposition);
>
> if (!NT_SUCCESS(Status))
> {
> *FileNames = NULL;
> NumberOfNames = 0;
> return Status;
> }
>
> if (Disposition == REG_CREATED_NEW_KEY)
> {
> *FileNames = NULL;
> NumberOfNames = 0;
> return Status;
> }
>
> BufferLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION)
> +256*sizeof(WCHAR);
>
> KeyInfo=ExAllocatePoolWithTag(
> NonPagedPool,
> BufferLength,
> 'knm');
>
> if (!KeyInfo)
> {
> ZwClose(hKey);
> *FileNames = NULL;
> NumberOfNames = 0;
> return STATUS_INSUFFICIENT_RESOURCES;
> }
>
> RtlZeroMemory(
> KeyInfo,
> BufferLength);
>
>
> *FileNames = ExAllocatePoolWithTag(
> NonPagedPool,
> 10*sizeof(UNICODE_STRING),
> 'fni');
>
> if (!KeyInfo)
> {
> ZwClose(hKey);
> *FileNames = NULL;
> NumberOfNames = 0;
> return STATUS_INSUFFICIENT_RESOURCES;
> }
>
> cnt = 0;
>
> try
> {
>
>
> while
> ((Status=ZwEnumerateValueKey(hKey,cnt,KeyValuePartialInformation,KeyInfo,BufferLength,&ret))!
> =STATUS_NO_MORE_ENTRIES)
> {
>
> if (cnt>=10)
> break;
>
> if (Status == STATUS_INFO_LENGTH_MISMATCH)
> {
> ExFreePoolWithTag(KeyInfo,'knm');
> BufferLength = BufferLength*2;
> KeyInfo=ExAllocatePoolWithTag(
> NonPagedPool,
> BufferLength,
> 'knm');
>
> }
>
> if (NT_SUCCESS(Status))
> {
>
>
> FileNames[0][cnt].Buffer = ExAllocatePoolWithTag(
> NonPagedPool,
> KeyInfo->DataLength,
> 'unm');
>
> if (!FileNames[0][cnt].Buffer)
> {
> ZwClose(hKey);
> *NumberOfNames = cnt + 1;
> return STATUS_INSUFFICIENT_RESOURCES;
>
> }
>
> RtlCopyMemory(FileNames[0][cnt].Buffer,KeyInfo->Data,KeyInfo-
>>DataLength);
> FileNames[0][cnt].Length=(USHORT)KeyInfo->DataLength;
> FileNames[0][cnt].MaximumLength=FileNames[0][cnt].Length;
>
> DbgPrint("Nume primit: %S\n",FileNames[0][cnt].Buffer);
> cnt++;
> }
> else if (Status !=STATUS_INFO_LENGTH_MISMATCH)
> break;
>
>
> }
>
> }
> except(EXCEPTION_EXECUTE_HANDLER)
> {
> Status=GetExceptionCode();
> DbgPrint("Exception raised: 0x%x",Status);
> ZwClose(hKey);
> if (KeyInfo)
> ExFreePoolWithTag(KeyInfo,'knm');
> *NumberOfNames = cnt + 1;
> return Status;
> }
>
>
>
> ZwClose(hKey);
> ExFreePoolWithTag(
> KeyInfo,
> 'knm');
>
> if (NT_SUCCESS(Status))
> *NumberOfNames = cnt;
> else
> *NumberOfNames = 0;
>
>
> return Status;
> }
>
> NTSTATUS FreeUnicodeStrings(
> PUNICODE_STRING *FileNames,
> ULONG NumberOfNames)
> {
> ULONG cnt;
>
>
> for (cnt=0; cnt<NumberOfNames; cnt++)
> ExFreePoolWithTag(FileNames[0][cnt].Buffer,'unm');
>
>
> ExFreePoolWithTag(*FileNames,'fni');
>
> return STATUS_SUCCESS;
> }
>
>
>
> and now the analyze from windbg
> it is kind of problematic because I have some problems with the
> symbols
>
>
> *******************************************************************************
> *
> *
> * Bugcheck
> Analysis *
> *
> *
> *******************************************************************************
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 50, {f888a490, 0, 8056c057, 0}
>
> Probably caused by : sfilter.sys ( sfilter!SfWrite+1eb )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3592 cc int 3
> kd> !analyze -v
> *******************************************************************************
> *
> *
> * Bugcheck
> Analysis *
> *
> *
> *******************************************************************************
>
> 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: f888a490, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: 8056c057, If non-zero, the instruction address which referenced
> the bad memory
> address.
> Arg4: 00000000, (reserved)
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: f888a490
>
> FAULTING_IP:
> nt!RtlCompareUnicodeString+46
> 8056c057 668b3a mov di,[edx]
>
> MM_INTERNAL_CODE: 0
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0x50
>
> LAST_CONTROL_TRANSFER: from f88842eb to 8056c057
>
> TRAP_FRAME: fc8e79d4 -- (.trap fffffffffc8e79d4)
> ErrCode = 00000000
> eax=e10b34d8 ebx=81262660 ecx=c1062004 edx=f888a490 esi=e10b3498
> edi=8117f758
> eip=8056c057 esp=fc8e7a48 ebp=fc8e7a60 iopl=0 nv up ei ng nz
> na po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010287
> nt!RtlCompareUnicodeString+0x46:
> 8056c057 668b3a mov di,[edx] ds:
> 0023:f888a490=????
> Resetting default scope
>
> STACK_TEXT:
> fc8e7a60 f88842eb e10b3488 f8883980 00000001 nt!RtlCompareUnicodeString
> +0x46
> fc8e7b24 804e37f7 81262660 81187a98 00000000 sfilter!SfWrite+0x1eb [c:
> \winddk\6000\src\filesys\filter\file_system_filter\sfilter.c @ 2311]
> fc8e7b34 804eeadd fc8e7b70 fc8e7d40 00000000 nt!IopfCallDriver+0x31
> fc8e7b48 804ee6a6 8117f70a fc8e7b70 fc8e7c04 nt!IoSynchronousPageWrite
> +0xaf
> fc8e7c24 804ed331 e14c2008 e14c200c e14c200c nt!MiFlushSectionInternal
> +0x38b
> fc8e7c60 804eed68 812500b0 e14c2008 00000000 nt!MmFlushSection+0x1b5
> fc8e7ce8 804ed178 00001000 00000000 00000001 nt!CcFlushCache+0x372
> fc8e7d2c 804e4f1d 812911e8 80561440 8128eb30 nt!CcWriteBehind+0xdc
> fc8e7d74 804e426b 812911e8 00000000 8128eb30 nt!CcWorkerThread+0x126
> fc8e7dac 8057be15 812911e8 00000000 00000000 nt!ExpWorkerThread+0x100
> fc8e7ddc 804fa4da 804e4196 00000000 00000000 nt!PspSystemThreadStartup
> +0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> sfilter!SfWrite+1eb [c:\winddk\6000\src\filesys\filter
> \file_system_filter\sfilter.c @ 2311]
> f88842eb 85c0 test eax,eax
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: sfilter!SfWrite+1eb
>
> MODULE_NAME: sfilter
>
> IMAGE_NAME: sfilter.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 469ab2f9
>
> STACK_COMMAND: .trap fffffffffc8e79d4 ; kb
>
> FAILURE_BUCKET_ID: 0x50_sfilter!SfWrite+1eb
>
> BUCKET_ID: 0x50_sfilter!SfWrite+1eb
>
> Followup: MachineOwner
> ---------
>
>
>
>> It would help if you included the bugcheck information (from windbg
>> !analyze -v command) and also the actual code rather your description of
>> the code.
>>
>> From your description I have no idea. Obviously you do have side
>> effects from your DriverEntry invocations of these functions.
>>
>> --
>>
>> =====================
>> Mark Roddy DDK MVP
>> Windows Vista/2003/XP Consulting
>> Hollis Technology Solutions 603-321-1032www.hollistech.com
>
>



Re: Strange error possibly because of code in driver entry by euacela

euacela
Mon Jul 16 04:36:18 CDT 2007

On Jul 16, 4:48 am, "David J. Craig" <d...@yoshimuni.com> wrote:
> Have you stepped through the code with windbg looking at each line and the
> results as it executes? Try using the non-source mode so you see each
> instruction execute and watch the target address to see if you have an
> error. An address can be valid but wrong and create overwrites in bad
> places.
>
> First, I would never allow a pointer to an array where the callee allocates
> the array to be other than NULL when the callee obtains control. You should
> check *FileNames and if not NULL return STATUS_INVALID_PARAMETER as this
> makes it too easy for the caller to cause memory leaks.
>
> The assignment of zero to NumberOfNames is a bad idea. You need the '*'
> prefix to indicate the ULONG and not nulling out the pointer. Set it to
> zero at the beginning of your routine and you can increment it as you find
> the keys. Also you only assume that ZwEnumerateValueKey can return
> STATUS_NO_MORE_ENTRIES, but the documentation shows four returns and doesn't
> exclude there being more than those four.
>
> Do you need to create the keys or must they be present? Will they need to
> be read in a boot driver? The 'software' keys are not available until much
> later. I would use ZwOpenKey instead of ZwCreateKey.
>
> Why are you using MmIsAddressValid? It serves no purpose that I can see and
> can fail as the WDK indicates it can return TRUE, but later access can
> produce a fault.
>
> Is the registry key unique to your product or a standard software key? If
> unique, put it under your product's or company's name.
>
> I skipped a lot of the code and do have my doubts about it, but the above
> should get you started.
>

Yes I need the reg in the boot time as well, what do you suggest. The
key can exist or not. When does the registry become avalible from the
boot.
Shoud I uses files. They become avalible much earlier right ?

The thing is that the function calls are ok in the driver entry.
Normally it shouldn't happen anything wrong.
I will try with files.
thank you



Re: Strange error possibly because of code in driver entry by Maxim

Maxim
Mon Jul 16 14:16:11 CDT 2007

SOFTWARE registry is not available until late in system initialization.

Kernel-mode code should not use SOFTWARE registry, only SYSTEM.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

<euacela@gmail.com> wrote in message
news:1184543873.031672.132340@g4g2000hsf.googlegroups.com...
> I hoe this helps
>
> NTSTATUS GetBackUpFileNamesFromRegistry(
> PUNICODE_STRING *FileNames,
> PULONG NumberOfNames);
>
> NTSTATUS FreeUnicodeStrings(
> PUNICODE_STRING *FileNames,
> ULONG NumberOfNames);
>
>
> NTSTATUS GetBackUpFileNamesFromRegistry(
> PUNICODE_STRING *FileNames,
> PULONG NumberOfNames)
> {
> NTSTATUS Status;
> HANDLE hKey;
> OBJECT_ATTRIBUTES ObjAttr;
> UNICODE_STRING RegPath;
> ULONG Disposition,BufferLength,ret,cnt;
> PKEY_VALUE_PARTIAL_INFORMATION KeyInfo;
>
>
>
>
> *NumberOfNames = 10;
>
>
>
> try
> {
> if (!MmIsAddressValid(FileNames))
> return STATUS_ACCESS_VIOLATION;
> }
> except(EXCEPTION_EXECUTE_HANDLER)
> {
> return STATUS_ACCESS_VIOLATION;
> }
>
> RtlInitUnicodeString(
> &RegPath,
> L"\\Registry\\Machine\\Software\\BackupXP");
>
>
> InitializeObjectAttributes(
> &ObjAttr,
> &RegPath,
> OBJ_CASE_INSENSITIVE,
> NULL,
> NULL);
>
> Status = ZwCreateKey(
> &hKey,
> KEY_READ|KEY_QUERY_VALUE|KEY_ENUMERATE_SUB_KEYS,
> &ObjAttr,
> 0,
> NULL,
> REG_OPTION_NON_VOLATILE,
> &Disposition);
>
> if (!NT_SUCCESS(Status))
> {
> *FileNames = NULL;
> NumberOfNames = 0;
> return Status;
> }
>
> if (Disposition == REG_CREATED_NEW_KEY)
> {
> *FileNames = NULL;
> NumberOfNames = 0;
> return Status;
> }
>
> BufferLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION)
> +256*sizeof(WCHAR);
>
> KeyInfo=ExAllocatePoolWithTag(
> NonPagedPool,
> BufferLength,
> 'knm');
>
> if (!KeyInfo)
> {
> ZwClose(hKey);
> *FileNames = NULL;
> NumberOfNames = 0;
> return STATUS_INSUFFICIENT_RESOURCES;
> }
>
> RtlZeroMemory(
> KeyInfo,
> BufferLength);
>
>
> *FileNames = ExAllocatePoolWithTag(
> NonPagedPool,
> 10*sizeof(UNICODE_STRING),
> 'fni');
>
> if (!KeyInfo)
> {
> ZwClose(hKey);
> *FileNames = NULL;
> NumberOfNames = 0;
> return STATUS_INSUFFICIENT_RESOURCES;
> }
>
> cnt = 0;
>
> try
> {
>
>
> while
>
((Status=ZwEnumerateValueKey(hKey,cnt,KeyValuePartialInformation,KeyInfo,Buffer
Length,&ret))!
> =STATUS_NO_MORE_ENTRIES)
> {
>
> if (cnt>=10)
> break;
>
> if (Status == STATUS_INFO_LENGTH_MISMATCH)
> {
> ExFreePoolWithTag(KeyInfo,'knm');
> BufferLength = BufferLength*2;
> KeyInfo=ExAllocatePoolWithTag(
> NonPagedPool,
> BufferLength,
> 'knm');
>
> }
>
> if (NT_SUCCESS(Status))
> {
>
>
> FileNames[0][cnt].Buffer = ExAllocatePoolWithTag(
> NonPagedPool,
> KeyInfo->DataLength,
> 'unm');
>
> if (!FileNames[0][cnt].Buffer)
> {
> ZwClose(hKey);
> *NumberOfNames = cnt + 1;
> return STATUS_INSUFFICIENT_RESOURCES;
>
> }
>
> RtlCopyMemory(FileNames[0][cnt].Buffer,KeyInfo->Data,KeyInfo-
> >DataLength);
> FileNames[0][cnt].Length=(USHORT)KeyInfo->DataLength;
> FileNames[0][cnt].MaximumLength=FileNames[0][cnt].Length;
>
> DbgPrint("Nume primit: %S\n",FileNames[0][cnt].Buffer);
> cnt++;
> }
> else if (Status !=STATUS_INFO_LENGTH_MISMATCH)
> break;
>
>
> }
>
> }
> except(EXCEPTION_EXECUTE_HANDLER)
> {
> Status=GetExceptionCode();
> DbgPrint("Exception raised: 0x%x",Status);
> ZwClose(hKey);
> if (KeyInfo)
> ExFreePoolWithTag(KeyInfo,'knm');
> *NumberOfNames = cnt + 1;
> return Status;
> }
>
>
>
> ZwClose(hKey);
> ExFreePoolWithTag(
> KeyInfo,
> 'knm');
>
> if (NT_SUCCESS(Status))
> *NumberOfNames = cnt;
> else
> *NumberOfNames = 0;
>
>
> return Status;
> }
>
> NTSTATUS FreeUnicodeStrings(
> PUNICODE_STRING *FileNames,
> ULONG NumberOfNames)
> {
> ULONG cnt;
>
>
> for (cnt=0; cnt<NumberOfNames; cnt++)
> ExFreePoolWithTag(FileNames[0][cnt].Buffer,'unm');
>
>
> ExFreePoolWithTag(*FileNames,'fni');
>
> return STATUS_SUCCESS;
> }
>
>
>
> and now the analyze from windbg
> it is kind of problematic because I have some problems with the
> symbols
>
>
>
*******************************************************************************
> *
> *
> * Bugcheck
> Analysis *
> *
> *
>
*******************************************************************************
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck 50, {f888a490, 0, 8056c057, 0}
>
> Probably caused by : sfilter.sys ( sfilter!SfWrite+1eb )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3592 cc int 3
> kd> !analyze -v
>
*******************************************************************************
> *
> *
> * Bugcheck
> Analysis *
> *
> *
>
*******************************************************************************
>
> 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: f888a490, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: 8056c057, If non-zero, the instruction address which referenced
> the bad memory
> address.
> Arg4: 00000000, (reserved)
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: f888a490
>
> FAULTING_IP:
> nt!RtlCompareUnicodeString+46
> 8056c057 668b3a mov di,[edx]
>
> MM_INTERNAL_CODE: 0
>
> DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO
>
> BUGCHECK_STR: 0x50
>
> LAST_CONTROL_TRANSFER: from f88842eb to 8056c057
>
> TRAP_FRAME: fc8e79d4 -- (.trap fffffffffc8e79d4)
> ErrCode = 00000000
> eax=e10b34d8 ebx=81262660 ecx=c1062004 edx=f888a490 esi=e10b3498
> edi=8117f758
> eip=8056c057 esp=fc8e7a48 ebp=fc8e7a60 iopl=0 nv up ei ng nz
> na po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010287
> nt!RtlCompareUnicodeString+0x46:
> 8056c057 668b3a mov di,[edx] ds:
> 0023:f888a490=????
> Resetting default scope
>
> STACK_TEXT:
> fc8e7a60 f88842eb e10b3488 f8883980 00000001 nt!RtlCompareUnicodeString
> +0x46
> fc8e7b24 804e37f7 81262660 81187a98 00000000 sfilter!SfWrite+0x1eb [c:
> \winddk\6000\src\filesys\filter\file_system_filter\sfilter.c @ 2311]
> fc8e7b34 804eeadd fc8e7b70 fc8e7d40 00000000 nt!IopfCallDriver+0x31
> fc8e7b48 804ee6a6 8117f70a fc8e7b70 fc8e7c04 nt!IoSynchronousPageWrite
> +0xaf
> fc8e7c24 804ed331 e14c2008 e14c200c e14c200c nt!MiFlushSectionInternal
> +0x38b
> fc8e7c60 804eed68 812500b0 e14c2008 00000000 nt!MmFlushSection+0x1b5
> fc8e7ce8 804ed178 00001000 00000000 00000001 nt!CcFlushCache+0x372
> fc8e7d2c 804e4f1d 812911e8 80561440 8128eb30 nt!CcWriteBehind+0xdc
> fc8e7d74 804e426b 812911e8 00000000 8128eb30 nt!CcWorkerThread+0x126
> fc8e7dac 8057be15 812911e8 00000000 00000000 nt!ExpWorkerThread+0x100
> fc8e7ddc 804fa4da 804e4196 00000000 00000000 nt!PspSystemThreadStartup
> +0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> sfilter!SfWrite+1eb [c:\winddk\6000\src\filesys\filter
> \file_system_filter\sfilter.c @ 2311]
> f88842eb 85c0 test eax,eax
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: sfilter!SfWrite+1eb
>
> MODULE_NAME: sfilter
>
> IMAGE_NAME: sfilter.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 469ab2f9
>
> STACK_COMMAND: .trap fffffffffc8e79d4 ; kb
>
> FAILURE_BUCKET_ID: 0x50_sfilter!SfWrite+1eb
>
> BUCKET_ID: 0x50_sfilter!SfWrite+1eb
>
> Followup: MachineOwner
> ---------
>
>
>
> > It would help if you included the bugcheck information (from windbg
> > !analyze -v command) and also the actual code rather your description of
> > the code.
> >
> > From your description I have no idea. Obviously you do have side
> > effects from your DriverEntry invocations of these functions.
> >
> > --
> >
> > =====================
> > Mark Roddy DDK MVP
> > Windows Vista/2003/XP Consulting
> > Hollis Technology Solutions 603-321-1032www.hollistech.com
>
>