LPC kernel - user : ZwConnectPort returns STATUS_OBJECT_NAME_NOT FOUND (0xC0000034)

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.