Please , do not relay for Debug prints output for debugging, and for
determining a succession of events. And also , please
use the debug symbols, you will make yourself a big favor. You are not using
an efficient development environment. Read Debugging tools for Windows help
and learn how to debug your problem.
> Output buffer length is 3136330376
Pretty big number , eh ? I dont think a 3Gb buffer was used for this IO 
“Sharanga Dayananda” wrote in
message news:xxxxx@ntfsd…
>
>
>
> -----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
>
>
>
>