[Bug 10293] sequentially running games/ apps with different SafeDisc versions fails

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10293





--- Comment #2 from Anastasius Focht <focht at 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


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.