MyDefrag4.3.1 keeps crashing

[stefhf]

I installed MyDefrag4.3.1 and it seems it installed two tasks in my task scheduler: MyDefrag v4.3.1 Daily and MyDefrag v4.3.1 Monthly .
At first the MyDefrag v4.3.1 Daily ran fine..I used it also as screensaver. But after a certain number of runs - I got the impression after my hard disk was fully defragmented - the daily task crashes all the time (so each day). See the attachment.
Why is this happening and what can I do to fix this?
Thanks in advance.

[Darlis]

Without the MyDefrag.debuglog it's just guessing. I'd guess it's the "Program Hints" crash. Look here for a solution.

If that's not the case, follow the steps in [FAQ] I have a problem! to create a debug log.

[BloodySword]

It's definitely not the program hints bug since the crash occurs while analyzing.

Run chkdsk c: /f to make the filesystem consistent. After that, you should check the drives SMART stauts. When it is not "good", then you should consider not defragmenting at all! You will loose data! So take a backup snapshot and go buy a new drive, when SMART values are bad.

[stefhf]

Thanks for replying but my SMART values are fine. Disk health is 100%.
Application Eventlog shows:

Faulting application name: MyDefrag.exe, version: 4.3.1.0, time stamp: 0x4bf62b1d
Faulting module name: MyDefrag.exe, version: 4.3.1.0, time stamp: 0x4bf62b1d
Exception code: 0xc0000409
Fault offset: 0x00000000000311a2
Faulting process id: 0x1eabc
Faulting application start time: 0x01cd1ea1d0ba9291
Faulting application path: C:\Program Files\System\MyDefrag v4.3.1\MyDefrag.exe
Faulting module path: C:\Program Files\System\MyDefrag v4.3.1\MyDefrag.exe
Report Id: 78bee754-8aa6-11e1-b11f-9be397c06e29

[Darlis]

The event log isn't helping much in this case. You have to upload the MyDefrag.debuglog. I've posted a link to the FAQ entry above.

[stefhf]

Thanks for replying Darlis.
I generated the MyDefrag.debuglog using the "Debug(175)" setting.
It's a 18 MB file and it's also filled with filenames which i rather keep private.
When i look into the file I see no errors as far as I can tell.
The script seems to be running fine from Date: 2012/04/28 05:01:14 to 06:32:58 and there is no error after the last line.
Is there any way to upload (some part of) the debuglog without mentioning all the filenames without manually editing the file?
I did do the latter and uploaded parts of the debugfile including the beginning en the end of the debugfile.

[Darlis]

Indeed, there is no error in the log file.

Please delete the debuglog, change the debug setting to 487 and run the script only on volume H: again. This will hopefully show more details. Did you run Checkdisk on the volume?

Usually only the first and last few hundred lines are important. You have to remove/rename any files you don't want to show up yourself, but be careful not to remove any hints to a problem

According to the volume stats in the debuglog: Is this a 3 TB disk you formatted with FAT32?

[stefhf]

Wow..you're fast Excellent support!
I did what you told me to do and I again removed the filenames from the debuglog.
Again no errors seem to appear in the log but the crash keeps occurring all the time.
You are right that disk H: seems to be causing the error and it's correct it is a 3TB disk formatted with FAT32 since I have a special need for the disk.
chkdsk finds no problems whatsoever:

chkdsk /f h:
The type of the file system is FAT32.
Volume ... created 14-2-2012 10:54
Volume Serial Number is 1210-312E
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
2.929.540.640 KB total disk space.
           96 KB in 3 hidden files.
       59.872 KB in 1.866 folders.
2.189.724.224 KB in 25.169 files.
  739.756.416 KB are available.

       32.768 bytes in each allocation unit.
   91.548.145 total allocation units on disk.
   23.117.388 allocation units available on disk.

[Darlis]

According to this article FAT32 is only supported for 2TB volumes. That may be what's causing the problem, but since there is (again) no error in the debug log, only Jeroen can tell what else could be the problem here.

[stefhf]

Well if it's not supported at all chkdsk should give an error too I guess?
But as a workaround..how can i modify the AutomaticDaily.MyD script to skip H: and nothing else?

[Darlis]

Put this line in the script before VolumeSelect:

Code:

ExcludeVolumes(Name("H:"))

If you put it in the Settings.MyD file MyDefrag will always skip this volume.

[stefhf]

Where should I put that line "ExcludeVolumes(Name("H:")) " in the Settings.MyD file?

[Darlis]

A yes, there is already an ExcludeVolumes statement in the Settings.MyD file. You can integrate your exclusion by replacing

Code:

ExcludeVolumes(CDRom(yes) or not(CommandlineVolumes()))

with

Code:

ExcludeVolumes(CDRom(yes) or not(CommandlineVolumes()) or Name("H:"))

[stefhf]

Thanks again!

[jeroen]

The debug logfile does not show that MyDefrag has crashed, so I suspect that it is Windows itself that is stopping MyDefrag. The logfile shows that MyDefrag was stopped when reading directory data close to the 3TB very end of the disk. I wonder if it might be a harddisk hardware problem, perhaps your harddisk has not been certified/tested by the manufacturer for FAT. At the moment I don't think this is a MyDefrag bug, although I cannot rule that out completely.