Recover from call to dll that doesn't return

[Renate Schaaf 79]

Ever since I work on my new Win 11 system, mediafoundation is acting up. (I use mfpack). Apparently microsoft is aware of some issues and has promised to fix them.

 

But right now the worst thing is that sometimes a call (IMFSourceReader.ReadSample) just doesn't return. The setup of the reader generates no errors, and it's not possible to see what is causing the hang in the dll (mfReadWrite.dll).

 

I've tried to intercept this by moving the call into a task and generating an exception on timeout. This is of course terrible for performance in a call which is used very often, but now at least I get an error message when it occurs. Still, the application hangs and the only way to solve this is to kill the application in taskmanager. 

 

Is there another way to recover from this, or do I just have to tell users "Sorry this file is not supported, go to taskmanager and terminate the application and never use this file again."?

[Lars Fosdal 1940]

Is it possible to delay-load the DLL explicitly - and unload / reload it after an exception?

 

Or walk the system app thread list and request termination of hung sub-threads in the DLL space?
(Clumsy description, but I hope you get what I suggest).

[Renate Schaaf 79]

8 minutes ago, Lars Fosdal said:

but I hope you get what I suggest

Thanks, I get the general idea, now I have the research the details 🙂

[Kas Ob. 158]

1 hour ago, Renate Schaaf said:

Is there another way to recover from this, or do I just have to tell users "Sorry this file is not supported, go to taskmanager and terminate the application and never use this file again."?

I don't think it is possible to recover from this, specially that i witnessed very similar behavior but without freezing part, it was refusing to initialize even there was nothing is loaded, the only thing that helped is restart the OS, and things returned working fine, in my case it happened after so many exceptions and debugging and stopping the debugged exe in the middle of an operation that was invoking WMF, the result in my opinion is the hardware part connecting it with the display part or the hardware decoder went rouge and left with dangling connections, so it refused in my case, in yours it might be behaved differently as it was waiting for some hardware signal that didn't come.

 

So, first you should confirm if this is the case and it caused by many faulty runs (stopped by exception or debugger), aka not clean exit, and an OS restart helped, and on other hand if you wasn't developing and changing stuff that raises exception and stops the operation without clean exit, then it will work as it should many many times.

 

That what comes to mind in this very case, as for recovery, then no that thread is done and gone, and i doubt creating new thread to resume the frozen one work will help, as it most likely will freeze too.

 

also watch carefully hardware acceleration effect and involvement on this case.

[Renate Schaaf 79]

32 minutes ago, Kas Ob. said:

I don't think it is possible to recover from this

It might get fixed, because a file for which ReadSample hangs, sometimes returns an error code on ReadSample, which is

MF_E_NOT_AVAILABLE                    = _HRESULT_TYPEDEF_($C00D36D6)

This seems to happen, if mf thinks that the input is protected, when actually it isn't. And that issue has been reported. 

Also, since you mention hardware acceleration, software encoding now never works. It returns with a sharing violation for a device. No idea what that could be. 

Being at the mercy of a new operating system almost makes me want to throw away the whole project. 

There are decoders which are no longer implemented by default (dolby ac-x), they can be downloaded but are very hard to find...