That explains something I've seen, I think. Comments on the shutdown process would be appreciated...
I have noted a couple of systems which have had historical problems with shutdown; after VNC is installed on them, I've had some confusing experiences where I attempt to connect after a (failed) remote reboot - and get the NT default background, sans logon box. In one extreme case where someone could not get to a box to reboot it for 3 days, you could connect remotely via VNC, get the screen, and of course do absolutely nothing. A few test port scans revealed absolutely nothing except for port 5900 responding (I don't recall whether I checked 5800). ----- Original Message ----- From: "Andrew van der Stock" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday/2002 March 06 08.15 Subject: RE: shutdown gotcha with Win32 host : It's not the way VNC hooks itself to the video driver, it's the way VNC : responds to the Service Control Manager's SERVICE_CONTROL_SHUTDOWN : message - in that we don't. VNC (correctly) dies as soon as the service : shutdown message is given. But there's a difference between stopping and : shutting down, and we can leverage that to try and remedy this issue. : : Here's the relevant bits from the VNCService.cpp file: : : 1019 case SERVICE_CONTROL_STOP: : 1020 // STOP : The service must stop : 1021 g_srvstatus.dwCurrentState = SERVICE_STOP_PENDING; : 1022 ServiceStop(); : 1023 break; : : And we do not assert that we are interested in SERVICE_ACCEPT_SHUTDOWN : in the next function: : : 1052 g_srvstatus.dwControlsAccepted = SERVICE_ACCEPT_STOP; : : Remedies? : : VNC must tell the SCM that it is interested in SERVICE_ACCEPT_SHUTDOWN. : This will postpone VNC's exit until after the services that do not : assert this flag, but since VNC has no other service dependencies, it : will be asked to go down as soon as the other services handlers have : been called. : : We simply ignore the message and set a dwWaitHint of five seconds and : keep the dwCheckpoint flag incrementing to ensure that we are not : killed. To ensure that the box goes down fairly promptly, VNC must watch : if another process (best bet: csrss.exe) from the current desktop dies, : or hook into the desktop logoff sequence. Once the trigger has been : given, it's time to go down. : : And we need a watchdog - if the shutdown hasn't occurred in say 20 : seconds (roughly the time the NT lets services live for without killing : them), VNC re-enters the land of the living by completely ignoring the : SERVICE_CONTROL_SHUTDOWN message. This makes the VNC process unkillable : if it survives the SCM trying to kill it, and it's the bane of all : system administrators everywhere. : : A potential problem is if the solution gets too complex. The more : complex it is to cover off all the corner situations, the harder it'll : be to make it reliable and robust. : : Andrew : : -----Original Message----- : From: [EMAIL PROTECTED] : [mailto:[EMAIL PROTECTED]] On Behalf Of Keith Hall : Sent: Wednesday, 6 March 2002 8:14 PM : To: '[EMAIL PROTECTED]' : Subject: RE: shutdown gotcha with Win32 host : : [snip] : : Naturally it would be nice for someone to have a real good think about : the : way VNC hooks into the display driver (reason I've been told that it : can't : be done easily) and ensure that it cannot be shut down until almost the : last : thing before reboot. : --------------------------------------------------------------------- : To unsubscribe, mail [EMAIL PROTECTED] with the line: : 'unsubscribe vnc-list' in the message BODY : See also: http://www.uk.research.att.com/vnc/intouch.html : --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
