[9.0 Final] Crash while changing directory

[wkasdo]

Hi,

Longtime user here, since 1998. This is the first time that I'm posting a bug here. 18 years of use for one single purchase! Amazing.

That said, this is the bug: sometimes, when I change to a new folder TC will crash. The eventlog says:

Code: Select all

Faulting application name: TOTALCMD64.EXE, version: 9.0.0.0, time stamp: 0x00000000
Faulting module name: KERNEL32.DLL, version: 10.0.14393.0, time stamp: 0x57899a29
Exception code: 0xc0000005
Fault offset: 0x000000000000c95c
Faulting process id: 0x2e30
Faulting application start time: 0x01d24c71b29a38bc
Faulting application path: C:\usr\wincmd64\TOTALCMD64.EXE
Faulting module path: C:\WINDOWS\System32\KERNEL32.DLL
Report Id: 0acd898c-486a-4ba3-8f3b-3acc394f0fa0
Faulting package full name: 
Faulting package-relative application ID: 

Windows 10, 1607, build 14393.

The error suggests an access denied. Can't be the folder itself, I have full control. Let me know if you need more info.

[ghisler(Author)]

Unfortunately I can't say anything about the reasons because the crash is in Windows kernel32 and not in TC.

I need some kind of stack trace. Could you use the tool Procdump to create
one for me, please:
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) with Ctrl+Shift+F5
3. Change 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 from c:\dumps.

[wkasdo]

Got it, I will set it up.

[ghisler(Author)]

Any news? Total Commander 9.0a will be released very soon - if you want to see this fixed, you need to send me a report now, otherwise it may take a long time until it gets fixed, sorry.

[wkasdo]

I didn't work over te weekend. The procdump config is in place, when the crash happens again I will update you.

[ghisler(Author)]

So, did it happen again during last week?

[redfox]

It seems to be a similar problem to this: http://www.ghisler.ch/board/viewtopic.php?t=45728

[ghisler(Author)]

Sorry, I can't do anything without a stack trace. It's a crash in the Windows kernel, maybe due to bad parameters or so.

[MarcinW]

I found 64-bit KERNEL32.DLL, version 10.0.14393.0 here and downloaded according PDB file from Microsoft.

The exception (an access violation) is at offset 0x000000000000c95c - this is inside an internal BaseDllAdvanceTextPointer function. This function parses INI file contents - it is used internally by high level functions, like GetPrivateProfileString and WritePrivateProfileString.

An access violation is when parsing INI file contents - more precisely when reading consecutive INI bytes from an AnsiChar memory buffer (a buffer containing 8-bit characters).

Since GetPrivateProfileString uses a buffer supplied by the caller (a caller passes buffer pointer and bufer size to a GetPrivateProfileString call), it is possible that - for some reason - TC passes buffer size that is larger then the real buffer size. Result: KERNEL32.DLL reads bytes beyond the end ot the real buffer, until it reaches an unmapped memory page and raises an exception.

Maybe adding try..except..end statements around GetPrivateProfileStringA/W calls, TIniFile.ReadString calls, TIniFile.ReadSections calls and TIniFile.ReadSection calls could help to find and fix the cause of the problem.

Regards

[ghisler(Author)]

Thanks for the analysis. I'm currently not aware of any location where the buffer would be smaller than the size reported. I'm using the same buffer type and size parameter almost everywhere (1024 characters).

[MarcinW]

Since GetPrivateProfileString uses a buffer supplied by the caller (a caller passes buffer pointer and bufer size to a GetPrivateProfileString call), it is possible that - for some reason - TC passes buffer size that is larger then the real buffer size. Result: KERNEL32.DLL reads bytes beyond the end ot the real buffer, until it reaches an unmapped memory page and raises an exception.

This was a mistake. A buffer - even invalid - passed to GetPrivateProfileString, can't be a cause of the problem.

I took a look at KERNEL32.DLL once again and... I can't see any possibility of raising an exception in the place where it was raised. In all cases:
- a pointer is validated before the memory access
OR
- there are other, earlier accesses to the same memory address, so an exception would be raised in other place.

So the only possibility that I can see here is a hardware error.

@wkasdo: Do you have overclocked CPU or RAM?

Regards