strange system worker thread in mrxsmb.sys question

Hello,

I have a scenario where a certain application writes out a file 1 or 2 bytes
at a time over the network over a network share. This file is in the
megabyte range. The creator of this application shall remain nameless to
prevent bodily injury and/or death threats to the author. In any case, it
is extremely inefficient in its writes to a particular file.

Regarding this scenario, I was wondering if anybody could explain the
following behavior, or point me in the right direction on a certain issue.
We have a file system filter driver filtering mrxsmb.sys, and in the case
where our filter is installed, using procmon, we see after each one of these
writes that a system thread is created using PsCreateSystemThread, it exits,
and then the next write is performed. In the case where our filter driver
is *not* installed, we only see the writes performed and the extra step of a
system thread being created and exiting is not shown. This information was
obtained using ProcessMonitor. Using ProcessMonitor to examine the stack of
this call to create the system thread, it is obvious that either mrxsmb.sys
or rdbss.sys is responsible for the creation. I’m presuming it is doing
some kind of work item or something, but that is only a guess.

Does anyone have any guesses as to what our filter could be doing to cause
mrxsmb.sys to be creating a system thread after a write operation? One
thing to note is that the operation completes as FAST_IO without us, but
with us it is done using a normal IRP_MJ_WRITE. Any ideas for further
investigation or theories explaining the behavior are appreciated.

The main problem is that this extra creation and destruction of a system
thread is badly exacerbating an already slow save time.

Thanks,
Matt

Does FastIo fail or it is not called at all? Which FastIo is called (FastIoCheckIfPossible/FastIoWrite/Both)?

There are symbols available for these drivers, so maybe name of the starting address of the system thread can give you some hint. Put breakpoint on read access to rdbss!_imp__PsCreateSystemThread and mrxsmb!_imp__PsCreateSystemThread. Then evaluate startRoutine parameter.

regards,
Bronislav Gabrhelik

In the case w/o our driver, FastIoCheckIfPossible is called and succeeds.
With our driver, the fast I/O check should fail. I must be missing
something; where can I get the symbols for these?

Matt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-359842-
xxxxx@lists.osr.com] On Behalf Of xxxxx@xythos.com
Sent: Monday, March 30, 2009 9:09 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] strange system worker thread in mrxsmb.sys question

Does FastIo fail or it is not called at all? Which FastIo is called
(FastIoCheckIfPossible/FastIoWrite/Both)?

There are symbols available for these drivers, so maybe name of the
starting address of the system thread can give you some hint. Put
breakpoint on read access to rdbss!_imp__PsCreateSystemThread and
mrxsmb!_imp__PsCreateSystemThread. Then evaluate startRoutine
parameter.

regards,
Bronislav Gabrhelik


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

I bet you must have set MSFT public symbol server in your Windbg. It is described in WinDbg help, but for the sake of…

File :: Symbol File Path…
srv*C:\symbols\symserv*http://msdl.microsoft.com/download/symbols;
where C:\symbols\symserv\ is your local symbol cache.

Then go to the Debug :: Modules. Select rdbss.sys and press “Reload” button. Repeat that once more for MrxSmb.sys, so now you have loaded symbols.

Verify that modules use PsCreateSystemThread():
x rdbss!_imp__PsCreateSystemThread
x mrxsmb!_imp__PsCreateSystemThread

Note: by this way you dump symbols from import table, so it reveals only static linking to DLL exports,but not dunamic usage of system routines (MmGetSystemRoutineAddress()).

Now you can put break on access.

ba r4 rdbss!_imp__PsCreateSystemThread

I hope it helps.
Bronislav Gabrhelik

>With our driver, the fast I/O check should fail.

It can be caused by “change buffering state” request.

  1. don’t you do non-cached read/write on the same file (I mean the same FCB not FO)
  2. twiddling with locks can cause it
  3. concurrent client oplock can cause it (I mean other client machine!)

Anyway I know that when you have write-only handle on MrxSMB, each write request is write-through. If you modify that in pre-create to be R/W, the write changes will not be propagated immediately to the server, so maybe it can improve performance.

Other thoughts.
If the platform is XP you can try to analyze rdbs!RxFastIoCheckIfPossible. The FCB/CCB (FO->FSContext/FO->FsContext2) should be the same like in IFS Kit/WDK headers. You can verify that Node type is expected (notetype.h). The Fcb.h header contains private version of FCB and the mrxfcb.h public version. The CCB is named FOBX (private) vs. MRX_FOBX (public).

Anyway that’s one more reason why MSFT SHOULD publish in WDK its mini-redirector core, which is other name for RDBSS.

Hope that helps
Bronislav Gabrhelik