Total Commander

At work I use TC in a VMWare VDI environment (Virtual Desktop).
The Desktop has as operating system: Windows 10 Enterprise 64-bit.
I have copied TC onto a Windows Share and I start TC directly from the Share; It’s not “Installed”.
The VDI Desktop is persistent so when I open the Desktop you can continue where you left off.

I happens a few times now that when I open my VDI Desktop and start using TC everything looks fine but after ~30 seconds / 1 minute TC hangs and display’s this crash report:

---------------------------
Total Commander 9.12
---------------------------
Control-C hit.
Control-C hit
Windows 10 10.0 (Build 16299), base: 0400000

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Stack trace (x64):46F910
46F910 46F910 46F910 46F910 46F910 46F910 46F910 46F910
46F910 46F910 46F910 46F910 46F910 46F910 46F910 46F910

Press Ctrl+C to copy this report!
Continue execution?
---------------------------
Yes No
---------------------------

Stack contents may suggest some infinite recurrency (although the error message not).

(And this is TC 9.12, not 9.20)

[mod]Moved to the 9.1x bug reports forum.

Hacker (Moderator)[/mod]

This happens when there is a C++ structured exception occuring in a third party DLL. The Lazarus/Free Pascal compiler I'm using cannot handle that correctly.

Solution: Use Total Commander 32-bit.

There is an architectural difference in 64-bit exception handling, so - basically - every DLL should handle its own exceptions.

But it should be still possible to catch the unhandled exception in the third-party 64-bit library - TC could install its own, additional exception handler by using an AddVectoredExceptionHandler API.

Regards

ghisler(Author) wrote:This happens when there is a C++ structured exception occuring in a third party DLL. The Lazarus/Free Pascal compiler I'm using cannot handle that correctly.

Solution: Use Total Commander 32-bit.

Is the 'third party DLL' an plugin configured within TC?
And is a possible workaround disabling the plugins???

It's probably not a plugin, but a Windows DLL misbehaving under VMWare VDI, or denying access via an exception.