TC75b7 access violation on exit

[waelder]

When I exit from TCMD I sometimes got an access violation:

Exception EAccessViolation in module TOTALCMD.EXE at 000648E1.
Access violation at address 00465B0D. Write of address 01A94059.

System: WinXP Prof. SP3 32bit with 2GB RAM. OODefrag 11 background monitoring is active.

[fenix_productions]

2waelder
Just my two cents:
http://www.ghisler.ch/board/viewtopic.php?p=170693#170693

Sorry I can't help more.

[ghisler(Author)]

Unfortunately I cannot reproduce this error on XP SP3 32bit. Maybe it happens only with specific settings, or after using a specific function in TC? Please try this:
1. Start Total Commander with fresh ini, e.g. via Start->Run:
c:\totalcmd\totalcmd.exe /i=c:\totalcmd\new.ini
and test whether you still get the error.
2. Start Total Commander with your settings and immediately close it. Do you still get the error?

[jvh]

I had the same problem here (WinXP Pro SP3):
Exception EAccessViolation in module TOTALCMD.EXE at 000648E1.
Access violation at address 00465B0D. Write of address 0127C1B1.

Starting TC with fresh ini helps, so I tried deactivate different plugins and I found that file system plugin Badcopy 1.0.0.4 caused these crashes (it's reproducable).
There were no problems with TC 7.50 b6 and less.


2 waelder:
It is possible that another (file system) plugins can cause crashes too, you can deactivate them very easily via TC Plugins Manager.

[alm]

I confirm this bug, but when I start TC several times it might not always happen when they are shutdown again.
It does not happen (so far) when it is started with:
c:\totalcmd\totalcmd.exe /i=c:\totalcmd\new.ini

Now that I have started it a few times with the option above, it does not happen with normal ini anymore.

Used OS: Windows XP Pro SP3 UK, with NL Multilanguage Pack.

Edit: It happens again.

[ghisler(Author)]

Sorry, I cannot reproduce the problem with BadCopy running either.

[jvh]

2 Ghisler

I tried to reproduce this error on another PC where BadCopy was also active but there weren't errors after upgrading to TC 7.50 b7. I enabled and disabled BadCopy plugin many times (>10) with TC Plugin Manager and closed TC (>10 per each try) but error on exit doesn't appear.
Then I deleted obsolete plugin link via TC Plugin Manager (only record in wincmd.ini, file didn't exist) and error with BadCopy appears. And it is reproducable again - with disabled BadCopy everything is O.K., with enabled TC crashes on exit almost each time. Strange...

[alm]

I don't use BadCopy, so it not only happens with BadCopy.

[ghisler(Author)]

There is one more thing which you could test:
Please add the following string to the file wincmd.ini, section [Configuration]:
ThreadFindFirst=0

You can edit the wincmd.ini via Configuration - Change settings files directly.

Does the error still occur then?

[jvh]

2 Ghisler

ThreadFindFirst=0 helps! No more crashes during short test.

I made another tests since yesterday and Badcopy realy isn't resposible for crashes because I record two ones with disabled Badcopy (but it was good "error accelerator" in my PC). The last thing which I discovered was when I changed startup directories in TC panels to empty ones error disappear... so it sounds for me that you hit the nail on the head. Thanks!

[alm]

ThreadFindFirst=0 seems to help. What is default value of this? I don't see it on other computers I work with.

It was ThreadFindFirst=1 on the computer where it gave error messages.

[Clo]

2alm

Hello !

• The default is now “1” with TC 7.5, but was “0” in previous versions…

 KR
Claude
Clo

[karlchen]

Hello, alm.

ThreadFindFirst=1 When set to 1, moves FindFirstFile to separate thread, so the user can abort reading from a hanging network connection

So the default value is 1 currently.
I have been using ThreadFindFirst=1 since the times when the default still was 0 and I have not had any crash on exit caused by ThreadFindFirst=1. This is true for my office machine which is connected to our company LAN as well as for my home machines which are not connected to any LAN.

So there must be at minimum one other factor which is relevant and which in combination with ThreadFindFirst=1 may lead to crashes on exit.

Kind regards,
Karl

[alm]

Ok, when ThreadFindFirst=1 is the default, then it must be something else causing this (or a combination), as I only have the issue on one computer so far. Although it now doesn't seem to crash when I exit.

[jy307@columbia.edu]

I can confirm also access violations upon exit. They are not reproducible. I will post more detail when I get it.