https://bugs.winehq.org/show_bug.cgi?id=38908 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |350ee62ab4ea40904296dcf90cf | |052938ca4ae75 --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello Sebastian, yes, it's that commit. I only reverted the 'device_file_ops' part of it for faster rebuild/test. --- snip --- $ git diff diff --git a/server/device.c b/server/device.c index e8ef832..c4954d4 100644 --- a/server/device.c +++ b/server/device.c @@ -198,7 +198,7 @@ static const struct object_ops device_file_ops = default_set_sd, /* set_sd */ no_lookup_name, /* lookup_name */ no_open_file, /* open_file */ - device_file_close_handle, /* close_handle */ + no_close_handle, /* close_handle */ device_file_destroy /* destroy */ }; --- snip --- --- quote --- Most likely we should store the client_{pid,tid} directly in the irp structure, and client_tid is NULL then? --- quote --- How would that be useful? As you said - at the time of process handle table destruction the process and all its associated threads are already dead ('current' = non-referenceable). The "close handle" IRP is dispatched to a device manager thread ('mountmanager' in this case) and ought to be fulfilled there. Unfortunately the device request "ping-pong" can't work here, there is no client to "reply" anymore. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.