After changes r18883/r18912 umpnpmgr.exe (and eventlog.exe) don't start
anymore. The problem is that they try to connect to the service control
manager using a named pipe (advapi32/service/sctrl.c function
ScConnectControlPipe). Before opening the pipe, a call is made to
WaitNamedPipe() to see if the pipe exists. This call currently fails,
resulting in failure of ScConnectControlPipe(), resulting in failure of
umpnpmgr.exe, resulting in network drivers not being installed, resulting in
no network connectivity.
WaitNamedPipe() NtOpenFile()s the pipe and then issues a FSCTL_PIPE_WAIT
ioctl. The problem is that this end of the pipe is now connected to the
server end (which is already listening) during the call to NtOpenFile() (in
function NpfsCreate(), setting the PipeStatus to FILE_PIPE_CONNECTED_STATE.
NpfsWaitPipe first checks the PipeStatus and bails out if it's not 0
(passive waiting state). So, in our case NpfsWaitPipe fails, 'cause the pipe
is already connected. The patch below just makes NpfsWaitPipe return success
in case it's already connected, which solves the umpnpmgr problem. However,
I don't think it's the correct solution, after the FSCTL_PIPE_WAIT ioctl
returns WaitNamedPipe() will close its end, so the server end sees an
unexpected close.
I have no clue how to proceed, and to be honest I'm not interested in
solving it myself. I'd rather see the author of the original patch take his
responsibility and fix the regression he introduced.
GvG.