Exception Thrown in Destructors Causing Program Crash

[mikasoukhov]

I've encountered an issue in WmiLight where destructors ( https://github.com/MartinKuschnik/WmiLight/blob/master/WmiLight/Wbem/IUnknown.cs#L22 ) are throwing exceptions, leading to the crash of the entire program. While this doesn't affect the original error in my case (no access to the native DLL), causing the entire program to crash is not ideal. This behavior should be addressed to prevent unnecessary crashes, even when the underlying error isn't critical.

[MartinKuschnik]

Hi @mikasoukhov, you are right. This should be changed.

I'm currently in vacation. Maybe you can create a PR?

[MartinKuschnik]

Version 6.5.1 changes the behavior.

[mikasoukhov]

I wanted to confirm that the issue is still present. The required file WmiLight.Native.dll is not found (although this might not be directly related to the current issue), and calling ReleaseIUnknown results in an exception, causing the application to crash.

To handle this more gracefully, it would be ideal to wrap the ReleaseIUnknown call in a try/catch block and log the exception details. For instance, using Trace.WriteLine to log the information would be a good approach. Additionally, it would be useful to log any previous errors or incorrect states returned by ReleaseIUnknown, even if it doesn't throw an exception.

I'm not familiar with the entire codebase, but if there are any other finalizers or similar code patterns elsewhere, it would be worth checking those as well to ensure they're handled properly.

[MartinKuschnik]

What's the reason that the dll is no longer present?

[mikasoukhov]

What's the reason that the dll is no longer present?

The missing DLL was my mistake – the program was incorrectly installed, and the runtimes folder was missing. After fixing that, everything worked. However, the application kept crashing before it could even log that a required file was missing. The reason is what I described earlier. Having the app crash like this is bad practice and should be handled better.

[MartinKuschnik]

I'd like to avoid the try/catch block you described.

Therefore i migrated to the methods AddRef, Release and QueryInterface provided by the Marshal class. This eliminates the edge case that the DLL is not longer presend.

This is also similar to the behavior of System.Management (e.g. IWbemClassObjectFreeThreaded).

I hope this solution is also sutable to you.

[mikasoukhov]

Glad I could help in finding a good solution, and thanks for the fix! Using managed classes is always better than explicit imports, and now everything looks much cleaner. If you don't hear from me in the next few days, that means everything is working well. :)

[MartinKuschnik]

Thanks a lot!