I’ve a sample LPC C/S that works as expected when client and server are in user mode (same app, actually). I keep the server code part running in user mode, and put the client (ZwConnectPort only so far) in kernel mode (e.g., in my_MRxCreateVNetRoot(IN MRX_CREATENETROOT_CONTEXT *createNetRootContextPtr) { …, just to get it going).
ZwConnectPort returns
#define STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034L)
This is the same setup that worked in user-user C/S mode. I traced into the ZwConnectPort through ObReferenceObjectbyName to ObpLookupDirectoryEntry (from memory) and from what I could see, only one object name was found - something like \SeRmConnectPort. The unicode string lengths were compared (different lengths so the string compare call wasn’t done) and not long after it set the *NAME_NOT_FOUND status code and came back up. It only tried to compare that one DirEntry/Object name based on a list of objects (end of list after that). I’m using “\WHATEVERPORT” as the name (whatever), and like I said, it all works fine when user-user.
I’m basing this on the example on this page:
http://www.zezula.net/en/prog/lpc.html
I’ve seen several LPC examples but all so far have been user-user based. I have yet to see anyone say they’ve gotten a kernel-user version going.
Any ideas on how to proceed?
Try using \BaseNamedObjects\YourPortName.
Win32 only sees the \BaseNamedObjects directory, and its object root is
this directory.
So, if a Win32 code creates the named object, it is placed to this
directory. Kernel code sees the whole namespace, so, it should add the prefix
of \BaseNamedObjects.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> I’ve a sample LPC C/S that works as expected when client and server are in
user mode (same app, actually). I keep the server code part running in user
mode, and put the client (ZwConnectPort only so far) in kernel mode (e.g., in
my_MRxCreateVNetRoot(IN MRX_CREATENETROOT_CONTEXT *createNetRootContextPtr) {
…, just to get it going).
>
> ZwConnectPort returns
>
> #define STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034L)
>
> This is the same setup that worked in user-user C/S mode. I traced into the
ZwConnectPort through ObReferenceObjectbyName to ObpLookupDirectoryEntry (from
memory) and from what I could see, only one object name was found - something
like \SeRmConnectPort. The unicode string lengths were compared (different
lengths so the string compare call wasn’t done) and not long after it set the
*NAME_NOT_FOUND status code and came back up. It only tried to compare that
one DirEntry/Object name based on a list of objects (end of list after that).
I’m using “\WHATEVERPORT” as the name (whatever), and like I said, it all works
fine when user-user.
>
> I’m basing this on the example on this page:
>
> http://www.zezula.net/en/prog/lpc.html
>
> I’ve seen several LPC examples but all so far have been user-user based. I
have yet to see anyone say they’ve gotten a kernel-user version going.
>
> Any ideas on how to proceed?
>
>
I wonder how many first posts stem from something like this…
I was running the LPC server code on the host machine last Friday, multiple, multiple times. I better just leave it at that, except to mention that I recognized it right away today, Monday, as soon as I tried to start (the absent) lpcSrv.exe.
\WHATEVERPORT worked from both sides.
Having winobj.exe would have helped Friday. I can see the port is there.
http://www.microsoft.com/technet/sysinternals/utilities/WinObj.mspx
Thanks for gentle handling - looking for BaseNamedObjects got some basic info in me.