MmGetSystemAddressForMdl bug check

NTFSD
1

Hi

I'm getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
occurs as I call MmGetSystemAddressForMdlSafe in the completion callback of
the IRP_MJ_QUERY_DIRECTORY.

Are there any problems inherent in W2k with this API call?

Cheers
Sha

InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology's supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it

2

This is not a bug in Windows 2000, this is a bug in your driver.

MmGetSystemAddressForMdlSafe can raise an exception. You are not protecting
your call to it using a try/except. However, NTFS does have a try/except
block and it is catching your exception. Debugging the exception (use the
current debugger and the documentation from it) is pretty well described and
if you examine the cause register you'll see the actual exception (something
like STATUS_QUOTA_EXCEEDED for example.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
Sent: Wednesday, July 10, 2002 11:24 AM
To: File Systems Developers
Subject: [ntfsd] MmGetSystemAddressForMdl bug check

Hi

I'm getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
occurs as I call MmGetSystemAddressForMdlSafe in the completion callback of
the IRP_MJ_QUERY_DIRECTORY.

Are there any problems inherent in W2k with this API call?

Cheers
Sha

InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology's supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information
visit
http://www.citc.it

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

3

Hi

Exactly where are these these exceptions (MmGetSystemAddressForMdlSafe)
described?

Cheers
Sha

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: 10 July 2002 16:38
To: File Systems Developers
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

This is not a bug in Windows 2000, this is a bug in your driver.

MmGetSystemAddressForMdlSafe can raise an exception. You are not protecting
your call to it using a try/except. However, NTFS does have a try/except
block and it is catching your exception. Debugging the exception (use the
current debugger and the documentation from it) is pretty well described and
if you examine the cause register you'll see the actual exception (something
like STATUS_QUOTA_EXCEEDED for example.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
Sent: Wednesday, July 10, 2002 11:24 AM
To: File Systems Developers
Subject: [ntfsd] MmGetSystemAddressForMdl bug check

Hi

I'm getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
occurs as I call MmGetSystemAddressForMdlSafe in the completion callback of
the IRP_MJ_QUERY_DIRECTORY.

Are there any problems inherent in W2k with this API call?

Cheers
Sha

InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology's supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information
visit
http://www.citc.it

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

You are currently subscribed to ntfsd as:
xxxxx@intechnology.co.uk
To unsubscribe send a blank email to %%email.unsub%%

This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information
visit
http://www.citc.it

==============================================
InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology's supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it

4

Nowhere.
They will be hopefully there in a future version of the DDK. But as far as I
know, MmGetSystemAddressForMdl
Safe wont raise on failure. The core API used by
MmGetSystemAddressForMdlSafe is MmMapLockedPagesSpecifyCache,
which IIRC will raise only if KPROCESSOR_MODE AccessMode is set to User
Mode. Why dont you give us a stack trace ? Also make sure you use correct
symbols. If possible, use a checked ntoskrnl build. And also, enable the
driver verifier for IO manager verifying.

Dan

----- Original Message -----
From: “Sharanga Dayananda”
To: “File Systems Developers”
Sent: Friday, July 12, 2002 1:55 PM
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

> Hi
>
> Exactly where are these these exceptions (MmGetSystemAddressForMdlSafe)
> described?
>
> Cheers
> Sha
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: 10 July 2002 16:38
> To: File Systems Developers
> Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check
>
>
> This is not a bug in Windows 2000, this is a bug in your driver.
>
> MmGetSystemAddressForMdlSafe can raise an exception. You are not
protecting
> your call to it using a try/except. However, NTFS does have a try/except
> block and it is catching your exception. Debugging the exception (use the
> current debugger and the documentation from it) is pretty well described
and
> if you examine the cause register you’ll see the actual exception
(something
> like STATUS_QUOTA_EXCEEDED for example.)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
> Sent: Wednesday, July 10, 2002 11:24 AM
> To: File Systems Developers
> Subject: [ntfsd] MmGetSystemAddressForMdl bug check
>
> Hi
>
> I’m getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
> occurs as I call MmGetSystemAddressForMdlSafe in the completion callback
of
> the IRP_MJ_QUERY_DIRECTORY.
>
> Are there any problems inherent in W2k with this API call?
>
> Cheers
> Sha
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@intechnology.co.uk
> To unsubscribe send a blank email to %%email.unsub%%
>
>___
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>__________________________________________________________________
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

5

This is the code I’m using ( this is from the completion callback; it’s
failing in METHOD_OUT_DIRECT )

if( IrpSp->Parameters.DeviceIoControl.OutputBufferLength > 0
)
{
DbgPrint( ( “Output buffer length is %lu\n”,
IrpSp->Parameters.DeviceIoControl.OutputBufferLength ) );

nBuffSize =
IrpSp->Parameters.DeviceIoControl.OutputBufferLength ;

switch(
IrpSp->Parameters.DeviceIoControl.IoControlCode & 3 )
{
case METHOD_BUFFERED:
DbgPrint( ( “METHOD_BUFFERED IO\n” )
);
if(Irp->AssociatedIrp.SystemBuffer
== NULL){
DbgPrint((“System Buffer is
NULL\n”));
break;
}

for( i = 0; i {
cCharacter = *( ( (char *)
Irp->AssociatedIrp.SystemBuffer ) + i );

DbgPrint( ( "%X “, ( int )
cCharacter ) );

if( cCharacter >= ’ ’ &&
cCharacter <= 127 )
{
DbgPrint( (”%c “,
cCharacter ) );
}
else
{
DbgPrint( (”. " ) );
}

if( i > 0 && i%80 == 0 )
DbgPrint( ( “\n” )
);

}
DbgPrint( ( “\n” ) );
break;

case METHOD_IN_DIRECT:
DbgPrint( ( “METHOD_IN_DIRECT implemented>\n” ) );
break;

case METHOD_OUT_DIRECT:
DbgPrint( ( “METHOD_OUT_DIRECT\n” ) );
DbgPrint( ( “Attempting to map MDL address
to system space\n” ) );
//MmProbeAndLockPages( Irp->MdlAddress,
KernelMode, IoReadAccess );
pBuffer = (unsigned char * )
MmGetSystemAddressForMdlSafe( Irp->MdlAddress, HighPagePriority );
DbgPrint( ( “MDL address successfully mapped
to system space\n” ) );
if( pBuffer == NULL )
{
DbgPrint( ( “Received a NULL buffer
from the MDL address\n” ) );
}
else
{

for( i = 0; i {
cCharacter = *( pBuffer + i
);

DbgPrint( ( "%X “, ( int )
cCharacter ) );

if( cCharacter >= ’ ’ &&
cCharacter <= 127 )
{
DbgPrint( (”%c “,
cCharacter ) );
}
else
{
DbgPrint( (”. " ) );
}

if( i > 0 && i%80 == 0 )
DbgPrint( ( “\n” )
);
}

}

DbgPrint( ( “\n” ) );

DbgPrint( ( “Attempting to unlock MDL
pages\n” ) );
MmUnlockPages( Irp->MdlAddress );
DbgPrint( ( “Mdl pages unlocked\n” ) );
break;

case METHOD_NEITHER:
DbgPrint( ( “METHOD_NEITHER
\n” ) );
break;
}
}
The output I seem to be getting from this is (including the stack dump) is

812ed6a0: CMD.EXE:812 IRP_MJ_CREATE C:\sha Attributes: Any Options:
Open Directory
812ed6a0: CMD.EXE:812 IRP_MJ_CREATE C:\sha Attributes:
Any Options: Open Directory

812ed6a0: Logging SUCCESS
812ed6a0: SUCCESS
812ed6a0: Output buffer length is 3136330376
812ed6a0: METHOD_OUT_DIRECT
812ed6a0: Attempting to map MDL address to system space
Second chance exception c0000005 (Access Violation) occurred
Thread stopped.
> kv
ffffffffbb2e3bdc 0000000000000000 NTOSKRNL!0xFFFFFFFF80455994 (No FPO)
>

Cheers
Sha

-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: 12 July 2002 12:46
To: File Systems Developers
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

Nowhere.
They will be hopefully there in a future version of the DDK. But as far as I
know, MmGetSystemAddressForMdl
Safe wont raise on failure. The core API used by
MmGetSystemAddressForMdlSafe is MmMapLockedPagesSpecifyCache,
which IIRC will raise only if KPROCESSOR_MODE AccessMode is set to User
Mode. Why dont you give us a stack trace ? Also make sure you use correct
symbols. If possible, use a checked ntoskrnl build. And also, enable the
driver verifier for IO manager verifying.

Dan

----- Original Message -----
From: “Sharanga Dayananda”
To: “File Systems Developers”
Sent: Friday, July 12, 2002 1:55 PM
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

> Hi
>
> Exactly where are these these exceptions (MmGetSystemAddressForMdlSafe)
> described?
>
> Cheers
> Sha
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: 10 July 2002 16:38
> To: File Systems Developers
> Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check
>
>
> This is not a bug in Windows 2000, this is a bug in your driver.
>
> MmGetSystemAddressForMdlSafe can raise an exception. You are not
protecting
> your call to it using a try/except. However, NTFS does have a try/except
> block and it is catching your exception. Debugging the exception (use the
> current debugger and the documentation from it) is pretty well described
and
> if you examine the cause register you’ll see the actual exception
(something
> like STATUS_QUOTA_EXCEEDED for example.)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
> Sent: Wednesday, July 10, 2002 11:24 AM
> To: File Systems Developers
> Subject: [ntfsd] MmGetSystemAddressForMdl bug check
>
> Hi
>
> I’m getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
> occurs as I call MmGetSystemAddressForMdlSafe in the completion callback
of
> the IRP_MJ_QUERY_DIRECTORY.
>
> Are there any problems inherent in W2k with this API call?
>
> Cheers
> Sha
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@intechnology.co.uk
> To unsubscribe send a blank email to %%email.unsub%%
>
>___
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>__________________________________________________________________
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntfsd as:
xxxxx@intechnology.co.uk
To unsubscribe send a blank email to %%email.unsub%%

_____________________________________________________________________
This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information
visit
http://www.citc.it
==============================================
InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology’s supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

_____________________________________________________________________
This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it

6

These cases will be described in future versions of the DDK documentation.
There have been a number of cases of Mm routines that raise exceptions but
those exceptions are not documented in the DDK.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Friday, July 12, 2002 7:46 AM
To: File Systems Developers
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

Nowhere.
They will be hopefully there in a future version of the DDK. But as far as I
know, MmGetSystemAddressForMdl
Safe wont raise on failure. The core API used by
MmGetSystemAddressForMdlSafe is MmMapLockedPagesSpecifyCache,
which IIRC will raise only if KPROCESSOR_MODE AccessMode is set to User
Mode. Why dont you give us a stack trace ? Also make sure you use correct
symbols. If possible, use a checked ntoskrnl build. And also, enable the
driver verifier for IO manager verifying.

Dan

----- Original Message -----
From: “Sharanga Dayananda”
To: “File Systems Developers”
Sent: Friday, July 12, 2002 1:55 PM
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

> Hi
>
> Exactly where are these these exceptions (MmGetSystemAddressForMdlSafe)
> described?
>
> Cheers
> Sha
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: 10 July 2002 16:38
> To: File Systems Developers
> Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check
>
>
> This is not a bug in Windows 2000, this is a bug in your driver.
>
> MmGetSystemAddressForMdlSafe can raise an exception. You are not
protecting
> your call to it using a try/except. However, NTFS does have a try/except
> block and it is catching your exception. Debugging the exception (use the
> current debugger and the documentation from it) is pretty well described
and
> if you examine the cause register you’ll see the actual exception
(something
> like STATUS_QUOTA_EXCEEDED for example.)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
> Sent: Wednesday, July 10, 2002 11:24 AM
> To: File Systems Developers
> Subject: [ntfsd] MmGetSystemAddressForMdl bug check
>
> Hi
>
> I’m getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
> occurs as I call MmGetSystemAddressForMdlSafe in the completion callback
of
> the IRP_MJ_QUERY_DIRECTORY.
>
> Are there any problems inherent in W2k with this API call?
>
> Cheers
> Sha
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@intechnology.co.uk
> To unsubscribe send a blank email to %%email.unsub%%
>
>___
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>__________________________________________________________________
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

7

-----Original Message-----
From: Sharanga Dayananda
Sent: 12 July 2002 14:24
To: ‘File Systems Developers’
Subject: RE: [ntfsd] RE: MmGetSystemAddressForMdl bug check

This is the code I’m using ( this is from the completion callback; it’s
failing in METHOD_OUT_DIRECT )

if( IrpSp->Parameters.DeviceIoControl.OutputBufferLength > 0
)
{
DbgPrint( ( “Output buffer length is %lu\n”,
IrpSp->Parameters.DeviceIoControl.OutputBufferLength ) );

nBuffSize =
IrpSp->Parameters.DeviceIoControl.OutputBufferLength ;

switch(
IrpSp->Parameters.DeviceIoControl.IoControlCode & 3 )
{
case METHOD_BUFFERED:
DbgPrint( ( “METHOD_BUFFERED IO\n” )
);
if(Irp->AssociatedIrp.SystemBuffer
== NULL){
DbgPrint((“System Buffer is
NULL\n”));
break;
}

for( i = 0; i {
cCharacter = *( ( (char *)
Irp->AssociatedIrp.SystemBuffer ) + i );

DbgPrint( ( "%X “, ( int )
cCharacter ) );

if( cCharacter >= ’ ’ &&
cCharacter <= 127 )
{
DbgPrint( (”%c “,
cCharacter ) );
}
else
{
DbgPrint( (”. " ) );
}

if( i > 0 && i%80 == 0 )
DbgPrint( ( “\n” )
);

}
DbgPrint( ( “\n” ) );
break;

case METHOD_IN_DIRECT:
DbgPrint( ( “METHOD_IN_DIRECT implemented>\n” ) );
break;

case METHOD_OUT_DIRECT:
DbgPrint( ( “METHOD_OUT_DIRECT\n” ) );
DbgPrint( ( “Attempting to map MDL address
to system space\n” ) );
//MmProbeAndLockPages( Irp->MdlAddress,
KernelMode, IoReadAccess );
pBuffer = (unsigned char * )
MmGetSystemAddressForMdlSafe( Irp->MdlAddress, HighPagePriority );
DbgPrint( ( “MDL address successfully mapped
to system space\n” ) );
if( pBuffer == NULL )
{
DbgPrint( ( “Received a NULL buffer
from the MDL address\n” ) );
}
else
{

for( i = 0; i {
cCharacter = *( pBuffer + i
);

DbgPrint( ( "%X “, ( int )
cCharacter ) );

if( cCharacter >= ’ ’ &&
cCharacter <= 127 )
{
DbgPrint( (”%c “,
cCharacter ) );
}
else
{
DbgPrint( (”. " ) );
}

if( i > 0 && i%80 == 0 )
DbgPrint( ( “\n” )
);
}

}

DbgPrint( ( “\n” ) );

DbgPrint( ( “Attempting to unlock MDL
pages\n” ) );
MmUnlockPages( Irp->MdlAddress );
DbgPrint( ( “Mdl pages unlocked\n” ) );
break;

case METHOD_NEITHER:
DbgPrint( ( “METHOD_NEITHER
\n” ) );
break;
}
}
The output I seem to be getting from this is (including the stack dump) is

812ed6a0: CMD.EXE:812 IRP_MJ_CREATE C:\sha Attributes: Any Options:
Open Directory
812ed6a0: CMD.EXE:812 IRP_MJ_CREATE C:\sha Attributes:
Any Options: Open Directory

812ed6a0: Logging SUCCESS
812ed6a0: SUCCESS
812ed6a0: Output buffer length is 3136330376
812ed6a0: METHOD_OUT_DIRECT
812ed6a0: Attempting to map MDL address to system space
Second chance exception c0000005 (Access Violation) occurred
Thread stopped.
> kv
ffffffffbb2e3bdc 0000000000000000 NTOSKRNL!0xFFFFFFFF80455994 (No FPO)
>

Cheers
Sha

-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: 12 July 2002 12:46
To: File Systems Developers
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

Nowhere.
They will be hopefully there in a future version of the DDK. But as far as I
know, MmGetSystemAddressForMdl
Safe wont raise on failure. The core API used by
MmGetSystemAddressForMdlSafe is MmMapLockedPagesSpecifyCache,
which IIRC will raise only if KPROCESSOR_MODE AccessMode is set to User
Mode. Why dont you give us a stack trace ? Also make sure you use correct
symbols. If possible, use a checked ntoskrnl build. And also, enable the
driver verifier for IO manager verifying.

Dan

----- Original Message -----
From: “Sharanga Dayananda”
To: “File Systems Developers”
Sent: Friday, July 12, 2002 1:55 PM
Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check

> Hi
>
> Exactly where are these these exceptions (MmGetSystemAddressForMdlSafe)
> described?
>
> Cheers
> Sha
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: 10 July 2002 16:38
> To: File Systems Developers
> Subject: [ntfsd] RE: MmGetSystemAddressForMdl bug check
>
>
> This is not a bug in Windows 2000, this is a bug in your driver.
>
> MmGetSystemAddressForMdlSafe can raise an exception. You are not
protecting
> your call to it using a try/except. However, NTFS does have a try/except
> block and it is catching your exception. Debugging the exception (use the
> current debugger and the documentation from it) is pretty well described
and
> if you examine the cause register you’ll see the actual exception
(something
> like STATUS_QUOTA_EXCEEDED for example.)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Sharanga Dayananda [mailto:xxxxx@intechnology.co.uk]
> Sent: Wednesday, July 10, 2002 11:24 AM
> To: File Systems Developers
> Subject: [ntfsd] MmGetSystemAddressForMdl bug check
>
> Hi
>
> I’m getting a bugcheck 0x24 (NTFS) in a file system filter driver. This
> occurs as I call MmGetSystemAddressForMdlSafe in the completion callback
of
> the IRP_MJ_QUERY_DIRECTORY.
>
> Are there any problems inherent in W2k with this API call?
>
> Cheers
> Sha
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@intechnology.co.uk
> To unsubscribe send a blank email to %%email.unsub%%
>
>___
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
> visit
> http://www.citc.it
>
>
> ==============================================
> InTechnology plc - Secure Offsite Data
> Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
> Main: 01423 850000
> Fax: 01423 858855
> www.intechnology.co.uk
>
> For a comprehensive list of InTechnology’s supplier accreditations visit
> our website accreditation page at
> www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp
>
>
>__________________________________________________________________
> This message has been checked for all known viruses by the
> CitC Virus Scanning Service powered by SkyLabs. For further information
visit
> http://www.citc.it
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntfsd as:
xxxxx@intechnology.co.uk
To unsubscribe send a blank email to %%email.unsub%%

_____________________________________________________________________
This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information
visit
http://www.citc.it
==============================================
InTechnology plc - Secure Offsite Data
Head Office: Nidderdale House, Beckwith Knowle, Harrogate, HG3 1SA.
Main: 01423 850000
Fax: 01423 858855
www.intechnology.co.uk

For a comprehensive list of InTechnology’s supplier accreditations visit
our website accreditation page at
www.intechnology.co.uk/html/reseller/techserv_R/res_accred.asp

_____________________________________________________________________
This message has been checked for all known viruses by the
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it