rejetto forum
Software => HFS ~ HTTP File Server => Bug reports => Topic started by: MarkV on May 03, 2007, 12:41:19 AM
-
OK, with my main desktop PC update went through just fine. But now with my notebook, it's another story:
- New version is downloaded
- A command line window opens and executes START /WAIT hfs.new.exe -q
The response from HFS is Access violation at address 74DD0CC2. Read of address 74DD0CC2.The error pops up twice, then the update finishes normally. But this error is annoying.
The only difference of both systems is, the notebook has an AMD Turion 64bit processor (but 32bit WXPHome) and the desktop AMD Athlon XP.
MarkV
edit: If I enter the command hfs.exe -q manually, the exact same error occours. It has nothing to do with update, but with quitting via command line parameter.
-
did the error come up using your computer through VNC ?
-
No not VNC, directly.
MarkV
-
#build number?
-
I must admit, the problem bugged me for many builds now, but I always ticked away the error messages too fast - sorry. :(
But it is definitely still occouring with #097. And it's only with this machine. Strange. ???
MarkV
-
can you give me address (of the violation) and build number?
the address is useful only with the build number.
since i lost sources for some builds, the #102 and #103 are good for sure.
-
2.2 build #103 experimental
Access violation at address 74DD0CC2, Read of address 74DD0CC2.
Occours everytime HFS is started a second time, be it for autoupdate (hfs.exe -q), or manually. Only 1 instance option is ENABLED. If I switch it off, NO error occours. But then autoupdate doesn't work anymore I guess. :(
Highest build the autoupdate offers is #97. Time for an update I think... ;)
edit: Could it be something with DEP (Data Execution Prevention) function of the CPU?
-
ok, i tried, and sadly that number is useless.
Occours everytime HFS is started a second time, be it for autoupdate (hfs.exe -q), or manually.
this is good, because it's easy to reproduce the problem.
what if you use the "add to hfs" command while hfs is running?
Could it be something with DEP (Data Execution Prevention) function of the CPU?
no idea
-
ok, i tried, and sadly that number is useless.
Occours everytime HFS is started a second time, be it for autoupdate (hfs.exe -q), or manually.
this is good, because it's easy to reproduce the problem.
what if you use the "add to hfs" command while hfs is running?
Same thing. This error always pops up twice.
Could it be something with DEP (Data Execution Prevention) function of the CPU?
no idea
This is the only machine with a 64bit CPU (but 32bit OS) and hardware DEP support. But it is not enabled for HFS...
Well, as the numbers are useless and it's only this computer I'm gonna blame the system itself. To be clear, this error does not prevent anything, that means, the update IS done correctly, HFS is not started a second time and even Add to HFS does what it should. I'll just ignore this error from now on.
I'll leave this thread open in case someone else has a similar problem. Meh... ;D
-
Well, update from #103 to #104 did not show any AV, but the error sound was to hear. Dr. Watson recorded an error c00000fd (stack overflow) in HFS. The rest of the file is useless as I have no symbols installed.
As I said, I'll ignore this error from now on, just thought I should mention it...
-
better than nothing :)
-
Sorry to revive this, but, with the update from build 119 > 120, the AVs are back. Ouch...
-
same address?
it may be a Delphi problem with 64bit CPU
-
Yeah, it's always the same address. To me it looks very high up in the address space.
I have one last thing to test: To opt-out of DEP and try again. Can I still fake an update with the special file? Else I would have to wait for the next update, which could be a while...
edit: stupid typo
-
yes, you can edit this file in the same folder of hfs.exe
-
No, I completely disabled DEP using the /noexecute=AlwaysOff policy in boot.ini, but it's still occouring. This pretty much rules out any DEP related setting.
(What the hell is he talking about? (http://support.microsoft.com/kb/875352/EN-US/))
Stays the 64bit Processor incompatibility. Or my notebook is to blame.
Maybe you could be so kind and seperate the update-code into a small commandline tool so I can check via batchfiles on this system?
Maybe like:
@echo off
hfs-up.exe /path="C:\Program Files\HFS\" /unstable=yes /downloadonly=yes
taskkill.exe /f hfs.exe
ren "C:\Program Files\HFS\HFS.exe" "HFS.old.exe"
ren "C:\Program Files\HFS\HFS.new.exe" "HFS.exe"
start "C:\Program Files\HFS\HFS.exe"
exit
Killing the HFS via TASKKILL works, I tested this.
hfs-up.exe with /downloadonly would allow me to only download the new build to HFS.new.exe and do the rest myself.
I know, the source is available, but I know zilch of coding... lol
-
START /WAIT hfs -q
ping 127.0.0.1 -n 3 -w 1000> nul
MOVE hfs.exe hfs.old.exe
MOVE /Y hfs.new.exe hfs.exe
START hfs.exe
-
This is essentially the batch file HFS executes when updating.
The lineSTART /WAIT hfs -qresults in (2 times)Access violation at address 74DD0CC2. Read of address 74DD0CC2.
This one line in the batch is my problem. I cannot invoke HFS from the commandline if it is already running, not even with -q.
@echo off
hfs-up.exe /path="C:\Program Files\HFS\" /unstable=yes /downloadonly=yes
if not exist "C:\Program Files\HFS\HFS.new.exe" goto end
taskkill.exe /f hfs.exe
ren "C:\Program Files\HFS\HFS.exe" "HFS.old.exe"
ren "C:\Program Files\HFS\HFS.new.exe" "HFS.exe"
start "C:\Program Files\HFS\HFS.exe"
:end
exit
My batch would work because TASKKILL quits HFS, not HFS itself.
-
does HFS save settings when killed by taskkill?
-
I have good news.
I got an error very similar to yours, and i was able to reproduce it every time, though i couldn't say how to do it in another system.
I also think i fixed it, so make a test and let me know.
www.dovedove.it/hfs/hfs123.exe
-
OK. Will test ASAP.
P. S. Are these silent updates? Or beta builds? My autoupdate won't pick it up...
-
i'm just publishing on the forum.
no autoupdate, sorry.
-
It seems to be fixed/smashed/whatever for good. No more AV, no more DrWatson. LOL.
Now that was a tough bugger...
edit: You don't mind me closing it? 'cause I wanted to do that for a long time. [Closed]
-
of course, to test, you just need to make an hfs -q
or similar
i'm collecting bug fixes before i publish an official update