http://bugs.winehq.org/show_bug.cgi?id=10293
--- Comment #2 from Anastasius Focht focht@gmx.net 2007-11-04 05:16:50 --- Created an attachment (id=8953) --> (http://bugs.winehq.org/attachment.cgi?id=8953) trace with WINEDEBUG=+tid,+seh,+loaddll,+ntoskrnl,+winedevice,+advapi,+relay
Hello,
--- quote --- winedevice is supposed to exit when the service is stopped, which will take care of the cleanup. --- quote ---
Hmm ... isn't winedevice supposed to be a "system process", which has special treatment in wine server? When a process is treated as "system process", it attaches an additional system-wide process event to wait the service request handler on (beside the ServiceMain threads). That means the pipe listening thread, handling service requests is kept alive until last user process exists (in this case the game).
So let me explain the situation again, maybe there was an misunderstanding...
A previous game start left an "incompatible" secdrv.sys in place - no processes running anymore. When the next game starts, it automagically starts the service, loading the wrong driver version. The process detects this and stops the service, replaces the binary, restarts service. While carrying out the service actions, the user process (game) is alive the whole time. Why should winedevice stop? It's a system process - by design...
So actually the service pipe listener is waiting - until another ServiceStart request arrives which results in ServiceMain thread created again in same winedevice.exe process.
Well, let me say few words about the "process exit" = "cure for all cleanup problems"... Although the wine server per process object directories are purged on process exit, I think it's good programming practice to have a clean shutdown sequence in winedevice too, allowing the kernel driver's Unload called. Just relying that process destroy cleans up all process objects/handle tables - including the leaked ones - to "fix" missing cleanups... uhm well. Having at least the driver unload called and unloading the binary _before_ user process exit sequence is a good thing (tm) to spot other bugs.
---
Attached is a trace log which shows the flow (with my patch applied so one can watch the whole show).
game, calling SCM api: 0x11
winedevice.exe:
main thread 0x18 pipe listener thread: 0x19 secdrv ServiceMain thread: 0x1A (terminates after SCM stop request)
secdrv ServiceMain: 0x1B
Regards