Defraggler Fails on XP64 Active Drive

[Gronxx]

On xp64, I have 4 HDDs with about 4 partitions each. Defraggler works just fine on the entire system—EXCEPT it has a glitch on the boot drive (E).

 

This is understandable to some extent. Because XP is on (E), asking Defraggler to work with (E) is asking a lot. But it can do it, as any defrag program can. But before and after it defrags that drive, I usually see a bad case of the MB data "trembling" or "vibrating". At first glance it looks like a defrag is in progress. However, it is really more like a freeze. The drive defrag may report "Complete", but the hourglass remains on.

 

Just once I was able to bring Defraggler back to life. However, 4 times now I have had to use Task Manager to kill the Defraggler process. And that isn't enough: as soon as I've retried it, the shaky numbers have resumed. Finally, for every one of those 4 instances, I had to uninstall Defraggler altogether.

 

I have no special settings. In fact, I'm using it out of the box while I troubleshoot this.

 

And, yes, I have been able to get it to successfully defrag Drive (E), which is healthy in every way. Nothing strange about it. But immediately before (when I first select Drive (E)) or after the successful defrag (ONLY with Drive (E), which does have the active xp64 on it) I get this quasi-hang.

 

I'm very close to dumping Defraggler. I wonder if it really is just right for 64-bit XP. I've seen other software, such as Heidi's Eraser, which can't really perform exactly right on xp64 even though it is supposed to. But Defraggler is my favourite of all defraggers ever, and I've used some of the big ones like OO. Never ever seen anything like this before. So I'd love to see Defraggler make peace with my boot drive.

 

Thank you.

[Guest MrRon]

Thanks for the detailed description, can you let me have a /debug log?

[Gronxx]

1. Re-installed Defraggler

2. Ran via df.exe using /debug3 log

3. The defrag itself ran perfectly, as (E) was already defragged

4. BUT in using this technique I was going around the GUI, and I think the problem may actually be with the GUI display???

 

In any case, my debug3 textfile = 42 MB: oops.

So I re-ran defrag with plainjane /debug log.

 

here is the log (attached)

Thank you.

 

_____________________________

EDIT, a few hours later:

 

?I have now tried df.exe E: several times, and it always works perfectly. I don't know much about these things, but I am getting a distinct impression that the glitch is in the GUI, rather than in the defrag program itself. I think the GUI goes as far as acknowledging the operation is complete, but then the GUI fails to extricate itself.

 

Meanwhile I can use df.exe when I want to defrag this partition.

 

I wonder if there are any other xp64 users trying this, and if so, if they have trouble with their boot partition(s).

 

(By the way, my system partition is C:. I usually multiboot 2-4 OSs, but I never run an OS on the system partition.)

 

Thanks again.

df.exe._1_15_163__2009_12_18_07_12_.txt

[Guest MrRon]

Thanks, we'll have a look at this.

[Gronxx]

Thanks. I do a lot of defragging. What I'm doing now is using the GUI for all my drives/partitions C through Q with the exception of E.

For Drive E (XP-64 boot partition) I'm using df.exe.

 

No GUI, no problem. The workaround works. But I'd like to be able to use the GUI for this partition too.

?I have done it so many times now that the glitch is definitely there. Never a problem using df.exe; always a problem before and after using the GUI.

?As I said previously, the defrag program is doing its job, and the difficulty is in the GUI itself.

 

For any other xp64 users: please test this out if you have multi drives/partitions.

I highly recommend Defraggler regardless of this glitch.

Thanks.

[Gronxx]

First try on this evening's new version 1.16.165, I have run it only once but I get the feeling it is working better and it SEEMS to be working faster.

 

Speed was no problem before, but it is just flying now! Maybe my imagination, but it seems so.

 

I was afraid to use the previous version on my xp64 boot drive (E), because the GUI Used Space and Free Space bytes display would go into a kind of endless loop which effectively froze the program and disabled my entire system session. (New readers: note that my boot drive is not the same as my system drive; and that I have 2 boot drives on this box.)

 

This new version showed the same fluttery bytes display at first, but this time I was able to use my mouse to get out of it and then return. [um?I think quite a few users would NOT be successful in persuading Defraggler to work by using my rather rough technique.] The bytes (Used Space and Free Space) still seemed to be a dishonest reporting, because despite the very high speed of the display, I was able to establish that the very same figures were alternating (quite a few times per second), whereas a genuine reporting would show continuously different figures.

 

Even so, the program got a hold on itself and completed the defrag of (E). It worked its way down to a good 0% frag end result. BUT on completion it continued to flutter the bytes display.

 

Okay, so that "fluttery display" begins the moment that my Drive (E) is first selected, BEFORE Defraggler has been given the Go Ahead to begin defragging, AND ALSO the same "fluttery display" continues AFTER the defrag is totally finished.

 

On no other drives or partitions does this happen. They all work perfectly.

 

The improvements I saw tonight on this first test were:

(1) I can actually get a successful defrag on the boot drive?although I would still prefer to continue using the line command for that drive

(2) Defraggler appears to be working faster

 

It's a big step in the right direction, but I think the bug in the GUI is still there. Less debilitating that before, but still there.

 

Thanks to Piriform for excellent work.

 

___________________________________

 

EDIT, a day or two later:

 

Subsequent tests show Drive (E) to be steady as it should be?no problems at all.

 

I don't know why the first test returned those results, unless there was still some element of the former build in operation.

 

At the moment, everything looks perfect.