Hi, Zebediah. Thanks for the detailed research. I've revert the first patch, applied the next one and the test was successful! Is the code fix as intended? If it is ok, I will send a PATCH v2.
diff --git a/dlls/quartz/systemclock.c b/dlls/quartz/systemclock.c index 73a923a7b99..0eb339420db 100644 --- a/dlls/quartz/systemclock.c +++ b/dlls/quartz/systemclock.c @@ -338,6 +338,7 @@ HRESULT system_clock_create(IUnknown *outer, IUnknown **out) list_init(&object->sinks); InitializeCriticalSection(&object->cs); object->cs.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": SystemClockImpl.cs"); + InterlockedIncrement(&object_locks);
TRACE("Created system clock %p.\n", object); *out = &object->IUnknown_inner;
2021年8月11日(水) 8:56 Zebediah Figura (she/her) zfigura@codeweavers.com:
On 8/10/21 6:40 PM, 粟田大樹 wrote:
Hi, Zebediah. Thank you for your quick reply.
It was a very interesting problem and I logged the changes in
object_locks.
In my tests, object_locks goes to 0 without system_clock_inner_Release being called. The game I tested does not have a free version, so I apologize for not sharing it. The game is clickable to skip video playback, and the crash occurs when clicking.
I have attached the log of my test for your reference. Thank you,
From examination of the code I believe the problem is that we call system_clock_create() from dsound_render_create(), which bypasses the increment.
Either that should be changed to CoCreateInstance, or we should only increment object_locks from creation functions. I'm kind of leaning toward the latter, even though it's more code, since it's more consistent (along the lines of "always grab and release a resource in the same place").
I note also that enum_reg_filter_create() and enum_moniker_create() don't reference the module, and should.