read kernel-mode buffer contents [was linker errors]

Thanks Tony and others. I shall try to use fltcreatefile and
fltreadfile.

But, before that, I want to quickly see how I use DbgPrint to display
the contents of the buffer. For eg., in FltReadFile (as is in
scanner.c),

status = FltReadFile( Instance,
FileObject,
&offset,
length,
buffer,
FLTFL_IO_OPERATION_NON_CACHED |

FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET,
&bytesRead,
NULL,
NULL );

Once the above function is successful, the buffer would be populated.
Now, I want to peek into the contents of buffer. So, I did the
following:
DbgPrint(“Contents of buffer: %s\n”, buffer);

But, this DbgPrint itself doesn’t show up. Not even the words “Contents
of buffer”. Maybe I am going wrong in the output formatting (0x%X ??) ?
I am able to see other DbgPrint values from the DbgViewer.

Please let me know how I can view the contents of the buffer from the
kernel-mode.

Thanks,
Sri.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Thursday, March 23, 2006 3:50 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] linker errors

Srivathsan_Srinivasagopalan wrote:

I am currently using DbgPrint to see what is going on (using
sysinternal’s dbgview) . But, I really need to log things into a file.

Hence, my question.

You can save the buffer from dbgview easily enough.

There are lots of places where it is not safe even to write to a file,
let alone open a new one (I’m not enough of an expert to know exactly
where these are so avoid it generally - keep kernel space simple, since
an error there can be catastrophic)… it’s generally not worth the
hassle just for logging.

If you really need to do this everywhere it’s probably safer to create a

communications port (FltCreateCommunictionPort) and run a service that
picks up the driver output and processes it. That way most of your
processing stays in userspace.

Tony


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.

Where do you expect the output to appear? Did you try adding a DbgPrint
to your DriverEntry function to confirm that you see even that? If not,
there’s something wrong with your environment, not with your code.

DbgPrint shows up in the debugger. Some tools (dbgview or dbgmon) trap
the debug print interrupt in the OS and “steal” the strings and send
them to a user mode application. I seldom run either of the latter
since I’m always running my own code under a debugger.

Regards,

Toy

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

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006.

Actually, I meant FltWriteFile (you were wanting to write a file, I
think, wasn’t really paying attention). I’m kinda surprised you seem to
of not caught MY error (you didn’t look in the docs, or, my error was
contagious). Don’t forget to close the handled returned from
FltCreateFile. Second, if you plan on writing drivers don’t use dbgview,
learn how to use a real debugger like Windbg. I’m fairly confident you
would see your dbgprint statement in a kernel debugger.

M

Srivathsan_Srinivasagopalan wrote:

Thanks Tony and others. I shall try to use fltcreatefile and
fltreadfile.

But, before that, I want to quickly see how I use DbgPrint to display
the contents of the buffer. For eg., in FltReadFile (as is in
scanner.c),

status = FltReadFile( Instance,
FileObject,
&offset,
length,
buffer,
FLTFL_IO_OPERATION_NON_CACHED |

FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET,
&bytesRead,
NULL,
NULL );

Once the above function is successful, the buffer would be populated.
Now, I want to peek into the contents of buffer. So, I did the
following:
DbgPrint(“Contents of buffer: %s\n”, buffer);

But, this DbgPrint itself doesn’t show up. Not even the words “Contents
of buffer”. Maybe I am going wrong in the output formatting (0x%X ??) ?
I am able to see other DbgPrint values from the DbgViewer.

Please let me know how I can view the contents of the buffer from the
kernel-mode.

Thanks,
Sri.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Thursday, March 23, 2006 3:50 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] linker errors

Srivathsan_Srinivasagopalan wrote:

>I am currently using DbgPrint to see what is going on (using
>sysinternal’s dbgview) . But, I really need to log things into a file.
>
>

>Hence, my question.
>
>

You can save the buffer from dbgview easily enough.

There are lots of places where it is not safe even to write to a file,
let alone open a new one (I’m not enough of an expert to know exactly
where these are so avoid it generally - keep kernel space simple, since
an error there can be catastrophic)… it’s generally not worth the
hassle just for logging.

If you really need to do this everywhere it’s probably safer to create a

communications port (FltCreateCommunictionPort) and run a service that
picks up the driver output and processes it. That way most of your
processing stays in userspace.

Tony


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Hi Tony,
I expect the output to appear in Dbgviewer (from sysinternals.com).

I just tried adding a DbgPrint statement in the DriverEntry routine. I
do not see that even!! It is weird. On the contrary, the DbgPrints I see
in the scanner.c code (which are already there as part of IFS kit) seems
to work fine and I see them showing up in the DbgViewer.

Regards,
Sri.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Thursday, March 23, 2006 6:13 PM
To: Windows File Systems Devs Interest List
Subject: RE: read kernel-mode buffer contents [was [ntfsd] linker
errors]

Where do you expect the output to appear? Did you try adding a DbgPrint
to your DriverEntry function to confirm that you see even that? If not,
there’s something wrong with your environment, not with your code.

DbgPrint shows up in the debugger. Some tools (dbgview or dbgmon) trap
the debug print interrupt in the OS and “steal” the strings and send
them to a user mode application. I seldom run either of the latter
since I’m always running my own code under a debugger.

Regards,

Toy

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

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006.


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.