Ok Tony,
actually I’m on this issue for a long now…
I’ve readen a lot about MUP and prefix claim:
RDBSS execs prefix claim in behalf of redirector.
The only way to inform RDBSS I’m the owner of a connection is returing
SUCCESS to MrxCreateSrvCall and MrxCreateVNetRoot!!
It’s what actually I do…
I’m debugging everything with SoftIce, CreateVNetRoot return STATUS_SUCCESS
on “\IPC$”
No other CreateVNetRoot will be triggered…
Here is the code for MrxCreateVNetRoot:
NTSTATUS AMRxCreateVNetRoot( IN PMRX_CREATENETROOT_CONTEXT
pCreateNetRootContext )
{
NTSTATUS Status = STATUS_SUCCESS;
PRX_CONTEXT pRxContext = pCreateNetRootContext->RxContext;
PMRX_V_NET_ROOT pVNetRoot =
(PMRX_V_NET_ROOT)pCreateNetRootContext->pVNetRoot;
PMRX_NET_ROOT pNetRoot = pVNetRoot->pNetRoot;
PMRX_SRV_CALL pSrvCall = pNetRoot->pSrvCall;
PWCHAR pRootName = (PWCHAR)(pNetRoot->pNetRootName->Buffer +
(pSrvCall->pSrvCallName->Length / sizeof(WCHAR)));
ULONG RootNameLength = pNetRoot->pNetRootName->Length -
pSrvCall->pSrvCallName->Length;
BOOL bCreateVNetRoot = FALSE;
if( pNetRoot->Context != NULL )
{
AMRxGetNetRootExtension( pNetRoot, pNetRootExtension );
bCreateVNetRoot = TRUE;
}
pNetRoot->MRxNetRootState = MRX_NET_ROOT_STATE_GOOD;
ASSERT( (NodeType(pNetRoot) == RDBSS_NTC_NETROOT) &&
(NodeType(pNetRoot->pSrvCall) == RDBSS_NTC_SRVCALL) );
// Check “\myserver”
if( pSrvCall->pSrvCallName->Length < 9 ||
( pSrvCall->pSrvCallName->Buffer[0] != ‘\’ ||
( pSrvCall->pSrvCallName->Buffer[1] != ‘M’ &&
pSrvCall->pSrvCallName->Buffer[1] != ‘m’ ) ||
( pSrvCall->pSrvCallName->Buffer[2] != ‘Y’ &&
pSrvCall->pSrvCallName->Buffer[2] != ‘y’ ) ||
( pSrvCall->pSrvCallName->Buffer[3] != ‘S’ &&
pSrvCall->pSrvCallName->Buffer[3] != ‘s’ ) ||
( pSrvCall->pSrvCallName->Buffer[4] != ‘E’ &&
pSrvCall->pSrvCallName->Buffer[4] != ‘e’ ) ||
( pSrvCall->pSrvCallName->Buffer[5] != ‘R’ &&
pSrvCall->pSrvCallName->Buffer[5] != ‘r’ ) ||
( pSrvCall->pSrvCallName->Buffer[6] != ‘V’ &&
pSrvCall->pSrvCallName->Buffer[6] != ‘v’ ) ||
( pSrvCall->pSrvCallName->Buffer[7] != ‘E’ &&
pSrvCall->pSrvCallName->Buffer[7] != ‘e’ ) ||
( pSrvCall->pSrvCallName->Buffer[8] != ‘R’ &&
pSrvCall->pSrvCallName->Buffer[8] != ‘r’ ) ||
( pSrvCall->pSrvCallName->Buffer[9] != ‘\’ &&
pSrvCall->pSrvCallName->Buffer[9] != 0x00 ) ) ||
RootNameLength < 1 )
{
Status = STATUS_BAD_NETWORK_NAME;
}
#ifdef _DEBUG_NETROOT
BWB_PRINT( “AMRX :: AMRxCreateVNetRoot :: %wZ on %wZ :: STATUS 0x%08lx\n”,
pRootName, pSrvCall->pSrvCallName->Buffer, Status );
#endif
if( Status != STATUS_PENDING )
{
pCreateNetRootContext->NetRootStatus = Status;
if( bCreateVNetRoot )
pCreateNetRootContext->VirtualNetRootStatus = Status;
else
pCreateNetRootContext->VirtualNetRootStatus = STATUS_SUCCESS;
pCreateNetRootContext->Callback( pCreateNetRootContext );
Status = STATUS_PENDING;
}
if( pNetRoot->Type == NET_ROOT_DISK )
{
pNetRoot->DeviceType = RxDeviceType( DISK );
}
return Status;
}
“Tony Mason” wrote in message news:xxxxx@ntfsd…
It sounds more and more like an implementation issue - perhaps you
aren’t claiming the prefix you think you are claiming for instance. But
of course this is difficult to diagnose without actually having the
machine in front of me to debug or a complete description of everything
that’s happening.
Not to single you out, but I know people often think on this list that a
problem they are seeing is something normal or standard but in fact
there are numerous problems that people encounter here that I’ve never
seen (and I’ve been doing this for a while and worked with a great many
file systems at this point.) To debug a problem like this often
requires providing a complete set of information - not because we need
it all, but because until we start looking at the data we don’t know
what we need next.
My suggestion is to look very carefully at the flow here and then review
your own code’s logic in this area.
Best of luck tracking it down - and let us know what you find so it
becomes part of the archive.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ale
Sent: Thursday, May 11, 2006 4:21 PM
To: ntfsd redirect
Subject: Re:[ntfsd] mini-rdr… Need to avoid IPC$ delay…
I’ve given it another check…
I actually receive one Prefix Claim via CreateVNetRoot for \IPC$ …and
I
return STATUS_SUCCESS
After it four (4) Create on “\MyServer\PIPE\wkssvc” and i return
STATUS_SUCCESS creating a valid - but not really true - response…
Then nothing more, in FileSpy these calls are floowed by an Open to
“\MyServer\IPC$” with STATUS_BAD_NETWORK_NAME, actually returned by LM!!
No other Prefix Claim or Open on “\IPC$” …
I do not understand the reason for which LM must issues this request…
I’ve
returned STATUS_SUCCESS on prefexic claim so I expect to be the owner…
Ale
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Then this must be a feature of RDBSS, which means you’re stuck with this
behavior. You could try building a separate (“buddy”) driver that
registers as a UNC provider (FsRtlRegisterUncProvider) and then
interacts with your own mini-redirector (so you could see the name
first) but that isn’t going to be a simple path to implement I suspect.
If you know anyone with the NT 4.0 IFS Kit, source code to an earlier
version of RDBSS was in that kit and you might be able to confirm this
behavior in that code base.
There may be someone else on list who has more experience with mini
redirectors and some further insight.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ale
Sent: Thursday, May 11, 2006 3:33 PM
To: ntfsd redirect
Subject: Re:[ntfsd] mini-rdr… Need to avoid IPC$ delay…
Hi Tony,
my provider is the first in such list…
During other prefix claim my rdr is always called as the first one…
Registry keys are:
HKLM\System\CurrentControlSet\Control\NetworkProvider\Order
HKLM\System\CurrentControlSet\Control\NetworkProvider\HwOrder
both on them lists my rdr as the first one…
I’ve already tried to return STATUS_SUCCESS on xxxMrxCreate instead of
returning an error code when a open reuqest on PIPE is performed…
Using FileSpy I can see that a request to \myserver\IPC$ is performed
with a
STATUS_BAD_NETWORK_NAME returned, and I do not return it…
Ale
“Tony Mason” wrote in message news:xxxxx@ntfsd…
There are two distinct places where this is an issue:
- In MPR, you have to list your NP dll before the LM dll. Otherwise you
get the long timeouts.
- In MUP, you have to load before LM loads otherwise you’ll have to wait
for 30 seconds while LM times out. It is possible that RDBSS explicitly
calls LM first, in which case you’re stuck with this behavior, but I’d
guess (without verifying this is true) that it just calls in the order
of loading.
Both of these are controlled by the order in the registry - one is the
MPR specific key for loading your NP, the other is the driver load
ordering specified in your service key relative to the MRXSMB service
key.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ale
Sent: Thursday, May 11, 2006 2:25 PM
To: ntfsd redirect
Subject: [ntfsd] mini-rdr… Need to avoid IPC$ delay…
Hi All,
I’m new user and your are my last way to address following issue…
Just few words:
When opening files with wmplayer or excel - it happens on other app too
-
application stays in hold for a lot!!
It happens because following requeste need to be processed:
\myserver\PIPE\srvsvc
\myserver\PIPE\wks…
\myserver\IPC$
…
my mini-rdr is registerd as UNC provider with MUP - I need to register
it or
wmplayer does not open files!! - and I actually process the prefix
claims of
MUP.
On CreateVNetRoot rdr does:
Checking pSrvCall->pSrvCallName and match it with “\myserver”
Set call-back status
Return STATUS_PENDING
On Create rdr does:
Return error code in case of NAMED_PIPE NetRoot
Opens other files on DISK NetRoot
Now, each time a file has been opened a IRP_CREATE is issued for
“\myserver\IPC$”
I’ve no way to process this OPEN which is processed by LANMAN, it take a
long to check for “\myserver” over the NET and get application in
hold…
Such OPEN are issued from explorer.exe wmplayer.exe system and so on…
at
the end it get application in hold for too much time…
It happens only on application UI, wmplayer start playing file withou
any
delay…
I really need help
Ale
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com