Okay, cool, thanks for the clarification.

Congrats on the 4.0, BTW!

Thanks for the tip! Sure enough, enclosing double quotes in single quotes works great. I'd have the same trouble with !allusersprofile! though, because it also resolves to a path with spaces (and the command would only see "del c:\Documents").

Just out of curiosity though, do I have to separate each space in the RunProgram command with a ","? That is, is "RunProgram("cmd /c del C:\file.txt")" valid, or would I have to segment it into "RunProgram("cmd","/c","del","c:\file.txt")"?

If you follow that, you know exactly what I mean.

Workflow:
Windows Setup extracts a WinRAR SFX archive containing mydefrag.exe, settings.myd, language.myd, and a custom script, to %allusersprofile%\Start Menu\Programs\Startup to run on first login.
SFX archive is triggered by first login, extracts itself to %temp%, launches MyDefrag, and exits.
A line in the script, after zone 1 is completed (to give the SFX enough time to exit), deletes the SFX archive from the Startup group - RunProgram("cmd.exe","/c","del","%allusersprofile%\startm~1\programs\startup\MyDefragNewPC.exe")
MyDefrag does its job and reboots the computer to complete Windows installation - WhenFinished(reboot)

Problem: %allusersprofile% needs to be in quotes since it resolves to C:\Documents and Settings... and includes spaces (it only sees the command as "del C:\Documents").

Solution: Enclose %allusersprofile%... in quotes.

Problem: ... How do you add quotes to something that is specified by quotes? Usually this is done by escaping, but I haven't found where escaping is documented in MyDefrag... 

For a few betas it was working good (before full-blown debug logging was re-enabled by default...), but now it trips all over itself again, by design

Isn't there another way that debug logging can be done by default, without writing an ever-growing file? Perhaps have it write a 50mb log file "container", then run the program and have it fill that file in? That way MyDefrag itself would be aware of its own log file, and it wouldn't be fragmented a thousand ways on the drive as MyDefrag moves data around...

I think the safe mode thing is a carry over from Windows 98, when defragging in safe mode was pretty much the *only* way to defrag the drive and not kill the hard drive, as there seems to have been a huge bug in the 98 defragger that was fixed in WinME, which was avoided in Safe Mode.

Not only would the actual read/writes be slower in safe mode, but the screen-drawing code in MyDefrag is already slow - imagine how slow it would be without a display driver running!

Thanks everybody for posting the logfiles! I have just released v4.0b6 that fixes the problem. Somehow the v4.0b5 distribution contained binaries from a test, where I purposely put code into the program to crash it, testing the new crash report code.

Ahaha, that's golden... well, it definitely works!

Thanks for the quick fix!

Did you see the thread at the very top of the page you were posting this new thread in...? Did you even look?

http://www.kessels.com/forum/index.php?topic=1818.0

Yeah, it's crashing for everyone right now. Gotta wait for Jeroen to come online and see what exploded...

Same here! Oops... looks like MyDefrag may need an emergency bugfix release

(we're just blazin' through the beta numbers!  )

Log attached. Crash occurs whenever I even run the program with no parameters, window doesn't come up, nothing.

Also noticed that it's trying to load files/scripts from the C:\Program Files\MyDefrag beta x folder, even when it's run from my Flash drive! Come on now, stick to your own program folder

Ahhhhh. That may explain why it would just "crash" with no explanation. I'll definitely include that when I update the set to Beta 4...

And don't worry, I'm not actually putting it on peoples' computers and like, "oh hey, use this instead of Windows defrag, it's better"... I just copy it, run it, and delete it, both because it's already a thousand times better than Defrag at straightening out a mangled hard drive, and to help with testing!
(Plus, it can't corrupt their files... *cough*... right?)

Just wondering what MyDefrag.pdb is... it seems to have "blown up" the installation package so clearly it would've been noticed and removed if it weren't important. I'd been omitting this file in my portable (day to day use) folder of MyDefrag, perhaps that's a clue as to that analyze-and-crash bug?

FWIW, I've encountered the same issues over a LAN RDC connection (not even Internet based). The commands came at the computer so fast that, indirectly, MyDefrag actually "flooded" the Remote Desktop client with drawing commands, and darn near crashed my (viewing) computer because the client was full-screen and wouldn't let me pull up the connection bar to back out of it. That was frustrating. It only really did this while it was processing directory entries and small files. I had to reduce the size of the MyDefrag window to get my computer back to a usable state... =\

Not sure exactly how to handle this though. Seems like it's not sending direct pixel updates as that wouldn't cause nearly as big a strain on the RDC client... =\

Well, it's not that they're marked as processed, but rather that the current implementation of FastFill only searches for files "forward" in the volume, instead of backward to previously skipped files (not vacated). It would make MyDefrag much faster to not "double move" all the files out of a vacated area (then move to their proper zone later), but we've got to wait until Jeroen finds and squishes the few remaining MyDefrag bugs before we can expect any changes in the way the program works (like caching and "proper" DoNotVacate operation)... =\

If the function actually does make use of the file cache, then oh my god I would absolutely love to see this implemented. It bugs me so much to see defraggers taking file move operations in such tiny pieces on systems with huge gigs of RAM available to it. Please please tell me this is possible! *drool*

edit: My simplified interpretation would be to simply "dummy read" the file (read the file to null), immediately prior to the move operation. Since the system disk cache is ever-changing and always caches the most recent read (as long as the file being read does not exceed the available space for cache - perhaps a limit of pre-reading size should be used), the next operation - moving the file - which consists of reading then writing, should just take its reads from the cache instead. Then it would only spend its time writing the data, then updating the MFT with the new location at the end. Ah yeah, that would be a welcome - and safe - improvement! 

And, once again, I was able to stop the crash from occurring by running the Windows defragger for about 5 minutes, then re-opened MyDefrag. Definitely the same bug...

I don't think it'll be RC or final until he gets that analyze-and-crash bug figured out