Ge van Geldorp wrote:
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.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Well, I can revert my kernel32 fixes, but then i guess that npfs doesn't ever get fixed ;) If you want me to, i'll do it immediately of course.
- Thomas