simrep SimRepReplaceFileObjectName

NTFSD
1

In the Windows 7 WinDDK simrep example, the function:
SimRepReplaceFileObjectName will try and re-use the existing buffer, but
if that is too small, SimRepReplaceFileObjectName will allocate it’s own
buffer.

I know that this function will cause a false-positive for the driver
verifier leaked pool test, is this because the replacement buffer is
allocated with the wrong tag?

Could the false-positive be avoided by allocating using ExAllocatePool
instead of ExAllocatePoolWithTag ?

I presume the swapped-buffer will be freed by the system. Will it use
ExFreePoolWithTag - and will it care that it has an unexpected tag?

– or are tags only considered when driver verifier is running?

(Why) isn’t there a ExReallocatePool()

And now some crazy talk

It seems that I can get some memory allocated from the correct pool by
calling ZwCreate on the filename I want, waiting for the open to arrive
at my minifilter, and then swap buffers with the original request and
then fail the ZwCreate that I’ve been given.

It’s clearly not worth the messing about or run-time overhead just to
avoid the false-positive, but it comes to mind.

Sam ?

2

Hi Sam,

The name in FileObject->FileName is allocated and freed by the IO manager. If you replace that buffer with your own and then unload before IO manager frees it verifier will see you have allocated some memory that is not freed when you unload, which looks exactly like a memory leak. The tags don’t matter as far as I know.

I wouldn’t worry about it unless you suspect you have other leaks and this false positive might mask them somehow.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

3

* Sam Liddicott wrote, On 15/10/09 14:11:

And now some crazy talk

It seems that I can get some memory allocated from the correct pool by
calling ZwCreate on the filename I want, waiting for the open to arrive
at my minifilter, and then swap buffers with the original request and
then fail the ZwCreate that I’ve been given.

It’s clearly not worth the messing about or run-time overhead just to
avoid the false-positive, but it comes to mind.

Or have another driver whose only job it is to do the alloc/swap?

Sam

4

You could do that too. But is that really necessary ? Why do you need to do this ?

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

5

Alex,
We call IoCreateFileSpecifyDeviceObjectHint to create new FileObject and
then free and allocate buffer. Then when we are finished we deallocate the
buffer just BEFORE calling ZwClose on file object…So shall we do not do
that? Can we be sure that IO manager will release the pool?

We tried that and Poolmon was showing it as memory leak.
Thanks
Ashish
On Thu, Oct 15, 2009 at 11:39 AM, Alexandru Carp <
xxxxx@microsoft.com> wrote:

Hi Sam,

The name in FileObject->FileName is allocated and freed by the IO manager.
If you replace that buffer with your own and then unload before IO manager
frees it verifier will see you have allocated some memory that is not freed
when you unload, which looks exactly like a memory leak. The tags don’t
matter as far as I know.

I wouldn’t worry about it unless you suspect you have other leaks and this
false positive might mask them somehow.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

6

Why exactly are you trying to fix this issue ?

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

7

Alex,
I did not understand the question ? Do you mean why we allocate/deallocate
the FileName buffer…We do this to pass Directory name to Query Attributes
of the directory…So we get Create for a file, we create fileobject using
the API IoCreateFileSpecifyDeviceObjectHint, pass in the directory path and
do query. After that we deallocate the buffer and call zwClose on
FileObject.

Thanks
As

On Thu, Oct 15, 2009 at 7:11 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:

Why exactly are you trying to fix this issue ?

Regards,

Alex.

This posting is provided “AS IS” with no warranties, and confers no rights
.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

8

No, the question is why do you care about that verifier check ? SimRep is doing the right thing with freeing and allocating a new buffer so if you are doing that then you are good. I would say ignore this particular verifier check under these circumstances.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

9

Alex,
There was a crash while NTFS was trying to access the filename for
its File Notifying function. I am not sure if that was related to this and
we might not cleanup name before Cleanup. If there anything till when the
filename should be visible?

Thanks
As
On Thu, Oct 15, 2009 at 8:47 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:

No, the question is why do you care about that verifier check ? SimRep is
doing the right thing with freeing and allocating a new buffer so if you are
doing that then you are good. I would say ignore this particular verifier
check under these circumstances.

Regards,

Alex.

This posting is provided “AS IS” with no warranties, and confers no rights.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

10

Hi Ashish,

Does the crash in NTFS repro with simrep ?

You don’t free the buffer you allocated. The system does.

Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.

11

Alex,
Sorry for late reply.

Here is the analysis from Microsoft (Customer went to Microsoft support)

*Analysis Summary:*

This dump shows the cause of the crash clearly. We knew from the last dump
that we were crashing because a CCB’s FullFileName buffer was prematurely
freed. This dump shows that DxSpy freed the buffer. DxSpy is freeing the
FileName buffer from the FILE_OBJECT, this is where we got the FullFileName
in the CCB. It should not being doing this and then calling IoCallDriver to
have more work done.

We do IRP_MJ_CREATE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_CLEANUP and
IRP_MJ_CLOSE. FileName buffer is releaser before IRP_MJ_CLEANUP.

Here is the stack trace of the crash

ChildEBP RetAddr Args to Child

b9386e94 f70b8d02 9f4c6fd8 a0beeb18 e1a43f50
nt!FsRtlNotifyFilterReportChange+0x148

b93870b4 f70b18d9 b93870d0 89d85090 a0316ee8 Ntfs!NtfsCommonCleanup+0x1fb5

b9387224 80840153 a0bee718 89d85090 89d85090 Ntfs!NtfsFsdCleanup+0xcf

b9387238 f7128d28 b93872c8 8ede6f38 89d852b0 nt!IofCallDriver+0x45

b9387264 80840153 a0316ee8 89d85090 80844ef5 fltmgr!FltpDispatch+0x152

b9387278 ba89a652 89d852b0 89d852d4 b93872c8 nt!IofCallDriver+0x45

WARNING: Stack unwind information not available. Following frames may be
wrong.

b9387290 ba8a1d80 a0316ee8 00000000 b93872c8 SYMEVENT+0x7652

b93872ac ba89a7b9 b93872c8 80844ef5 ba89a880 SYMEVENT+0xed80

b93872ec 80840153 97480f10 89d85090 89d85090 SYMEVENT+0x77b9

b9387300 f7128b25 a03b6ee8 89d85090 a0196c18 nt!IofCallDriver+0x45

b9387324 f7128cf5 b9387344 a03b6ee8 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

b938735c 80840153 a03b6ee8 89d85090 956f4d98 fltmgr!FltpDispatch+0x11f

b9387370 b90c9cc1 956f4fbb 956f4d98 00000000 nt!IofCallDriver+0x45

b93873d0 b90c9da3 9142af90 a03b6ee8 956f4fbb DxSpy+0xbcc1

b9387434 b90cb658 9142af90 a03b6ee8 956f4fbb DxSpy+0xbda3

b9387500 b90d4c55 00000144 a03b6ee8 8a000046 DxSpy+0xd658

b9387530 b90c0b6d 00000001 9908cd48 a03b6ee8 DxSpy+0x16c55

b93875c4 b90cebbd a03b6ee8 956f4d98 956f4fbb DxSpy+0x2b6d

b9387610 b90cedbb 89f9e430 9b358ffc 89f9e430 DxSpy+0x10bbd

b9387638 8083ffb5 8a253ad0 956f4d98 89f9e430 DxSpy+0x10dbb

Thanks
Ashish

On Fri, Oct 16, 2009 at 12:04 PM, Alexandru Carp <
xxxxx@microsoft.com> wrote:

Hi Ashish,

Does the crash in NTFS repro with simrep ?

You don?t free the buffer you allocated. The system does.

Regards,

Alex.

This posting is provided “AS IS” with no warranties, and confers no rights.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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