TC10.50b1+: crash after waking up the system

[Usher]

To figure out which plugin is causing it, I recommend that you temporarily remove half of them from the wincmd.ini, and then test. If the bug is gone, the problem plugin was in that half you removed, otherwise it's in the half that remained active. Then continue with half etc. until only one remains.

But imagine how much I, with my 380 plugins,

Really? You don't need even 10 times.
380 < 2^9=512

[Fla$her]

Well, you can start with those that you've added or updated recently.

I haven't updated anything to 10.50b1 for a long time. Therefore, this is unlikely to help.

my plugins do

You understand that 380 - yours =...

9 times.

Entertaining math. But no. That's not how it works. I immediately wrote that the problem is not permanent. That is, the number of falling asleep/waking up can be immediately multiplied by 6, if you focus on the frequency of appearances per month. You may have read above that I cannot test the system with groups of forced sleep calls, which means that all this will drag on indefinitely.

[Usher]

2Fla$her
Just do the test 9 times...
If no crash happens, maybe you can live with a workaround: Unload all plugins with cm_UnloadPlugins and only then shutdown your system. If it's really a problem with buggy plugins, TC with unloaded plugins shouldn't crash any more after waking up.

[Dalai]

A more direct approach could look like this: As soon as the issue occurs, don't close the error dialog. Instead, start Process Hacker, look for the crashed totalcmd.exe process, double-click on it and switch to the "Modules" tab. Copy the whole list (Ctrl+A, Ctrl+C) and paste it into an editor. There you can search for the various TC plugin type files. The list is reduced to the ones loaded at the time, so it's probably not in the hundreds. Since Process Hacker also lists the modules' base addresses, it could help to look for the one that's closest to the error address shown in the dialog. Note that the base address must be smaller than the one from the error message.

Regards
Dalai

[Fla$her]

2Usher
Unfortunately, calling cm_UnloadPlugins twice drops my TC, so it doesn't suit me.

2Dalai
Thanks. I will definitely use the advice, especially since Process Hacker is always in sight in my dockstation.

Note that the base address must be smaller than the one from the error message.

Can you explain in more detail?

[Dalai]

Unfortunately, calling cm_UnloadPlugins twice drops my TC, so it doesn't suit me.

You mean TC just closes after cm_UnloadPlugins is called? That's another indication that some plugin behaves badly.

Note that the base address must be smaller than the one from the error message.

Can you explain in more detail?

When you look at the base addresses shown in the "Modules" table in Process Hacker, you'll notive that they're "round" values, e.g. 0x75d90000. That's the base where a specific module is loaded. Every module has an address space, an area in memory which it can use for its operation. As far as I know (anybody correct me if I'm wrong), when a module allocates a chunk of memory, that memory's address is somewhere above the module's base address. Hence the base address must be smaller than the error address.

See also Wikipedia: https://en.wikipedia.org/wiki/Base_address

Regards
Dalai

[Fla$her]

You mean TC just closes after cm_UnloadPlugins is called? That's another indication that some plugin behaves badly.

After a double call. And this is another old problem that appeared a few versions ago. Rather, it is related to autorun.wdx and the unloading of its sub-plugins.

About modules. Can you show an example with one of the above errors? What should I match and how do I search for Base address in a large list? Now there are 225 positions there. Do I need to convert hexadecimal numbers to integers?

[Dalai]

Can you show an example with one of the above errors?

Let's use 0x0E610224 from the second access violation message. The base for this address could be 0x0E610000, but it might be even smaller like 0x0E600000. "It depends" like they always say .

[...] how do I search for Base address in a large list? Now there are 225 positions there.

For a first test I would ignore all DLLs, certainly all Microsoft/Windows DLLs. That should reduce the number significantly.

If you don't find the culprit among the TC plugins, include the shell extensions again, i.e. DLLs that are not from Microsoft.

Do I need to convert hexadecimal numbers to integers?

No need. The base addresses are given in hex as well as the address(es) in the error message. If you need to calculate, you can do that directly in Hex mode in Windows Calculator by setting its view/mode to "Programmer", or using Windows XP's calc.exe which has the hex mode in "Scientific" view.

Regards
Dalai

[Fla$her]

but it might be even smaller like 0x0E600000.

And what is the approximate range? If the difference is large, then it will be difficult to orientate by hex.

About Microsoft it is clear, thanks.

If you need to calculate

What to calculate? I can convert in a bunch of ways, not just with a standard calculator. The array is easier to process with a script. The only question is necessity.

[Dalai]

And what is the approximate range? If the difference is large, then it will be difficult to orientate by hex.

Honestly, I have no idea. I don't know enough about process memory management and don't know how large a single module's address space can be. However, the table in the "Modules" tab can be sorted by "Base Address", that should make it easier to look for the closest value.

Regards
Dalai

[Fla$her]

2Dalai
That's why I'm writing about the need to convert values to integers so that there is a normal opportunity to navigate in a sorted list.

Anyway, thanks. Hope this helps.

[ghisler(Author)]

Since the crash isn't caught by Total Commander but by Windows itself, you could use the tool Procdump to create a crash dump which should give a clue about the affected dll or plugin:
https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

1. Create new directory c:\dumps
2. Create a lnk file of procdump.exe or procdump64.exe (for 64-bit Windows)
in Total Commander with Ctrl+Shift+F5, e.g. procdump.lnk
3. Open the properties of the lnk file with Alt+Enter
4. Change the command from c:\path\procdump.exe to
"c:\path\procdump.exe" -ma -i c:\dumps
5. Important: Click on "Advanced" and check option "As administrator"
6. Run procdump with this link file
7. Wait until the crash occurs.
8. Send me the dump file from c:\dumps (just ONE is sufficient).

[Fla$her]

2ghisler(Author)
6. The console flashes and nothing happens. No monitoring process remains. Isn't it supposed to be done after a failure?

[AntonyD]

6. The console flashes and nothing happens.

that's a right behavior;)
now in your system this app was registered as post-mortem debugger.
And IF and only when The crash will happen - then this app will try to intercept the special internal call to kernel functions and made his task - to safe a properly created dump file at the specified directory: -i c:\dumps
Thus now you can send it - when it will be ready there. Which means that you should perform next point of action list:

7. Wait until the crash occurs.

[Fla$her]

2Dalai
The error appeared again:

Exception EAccessViolation in module TOTALCMD.EXE at 0A0FEFD8.
Access violation at address 0A500224. Read of address 0A500224.

Int: 173015588. Based on your method, I came to IsDotNET.wdx (is involved in tooltips for *.exe and libraries).

cudalister.wlx, 0x96c0000 158072832
exeinfo.wdx, 0xa0b0000 168493056
IsDotNET.wdx, 0xa490000 172556288
AKPic.wlx, 0xa570000 173473792

What's next?

2ghisler(Author)
Procdump reacted to another app a couple of days ago. And in this case, no reaction.