4 replies to this topic

[Atari800XL]

OK, after a lot of (slightly tedious) builds and testing (with strange errors), my problem seems to boil down to this:

- Latest WinPE_SE (v.36, 20120416)
- Clean build
- Only extra app: Autohotkey.exe, RunFromRam,True (so it's on X:)
- Add_Shortcut,Autostart,,,,,y:\portable\autohotkey.ini
(so it looks for it's startscript on y:, which is the USB stick.)

On a hp nc6320 (my testnotebook), this doesn't work when the system is "cold-booted" (so power off, then power on). The file Y:\portable\autohotkey.ini is not found. (So I guess the drive is not "ready" in time)
It only works on a warm boot (power on, reboot). After that, no more problems, so only on cold boot!

With my previous build (v.17, 20120107, or around that date), this doesn't happen (tested). No problems on cold boot. It might have something to do with the brand of USB, but I don't expect that (they're all Kingston).

What could be the cause of this, and what can I do to prevent it? Maybe some kind of "Wait for Y:" I can put in somewhere? For the time being, I will do more testing, but I hope somebody has a better (permanent) solution. Thanks!

Thanks also for a great program (WinBuilder), Project (WinPE_SE), and forum!!!

Edited by Atari800XL, 06 May 2012 - 10:55 AM.

[Atari800XL]

Did some more testing, best solution seemed to be adding a small "wait.exe" as autorun, all it does is wait for "y:\autohotkey\autohotkey.ini" to become available.

For testing purposes, I added a little counter. Turns out it *is* necessary to wait, from time to time. (counter is not 0, as it should be!!)

I still wonder how something like this can happen, my conclusion is that you cannot be 100% sure that Y:\ (=the USB drive), is available at systemstart (Autorun level).

[sbaeder]

Are you using at all the script that maps the "boot" drive to "Y" (i.e. CdDrive - X: - Y:) ?? There were posts a while back about things like this, and so Chris had to add some looping and waiting for the drive to be remapped.

I'm not sure of the timing, but there is a comment in there for v6 that they changed an option to accommodate PXE booting...I know that the executable does the remapping based on the existance of the file it puts in the target area (CdUSB.Y) but maybe something in the exe was also changed.

If you still have the older build, can you tell which version of the script you have? Also, check the "log" file - i.e. cdusb.log...most likely in the :WindowsSystem32 area...You should see what it is doing there and if it is also "looping" to wait to "remount" the boot media...


Scott

[pscEx]

Maybe it would be helpful to do something like multiPE does:

...
Launch2=%SystemRoot%System32RemapDrives.exe|/x Y: /t 10 /i 0
...
Launch5=%SystemRoot%System32IconRefresh.exe||SILENT
...

The boot waits e.g. for the RemapDrives, before it does anything else.

Peter

[Atari800XL]

I checked the versions, the "older build" (that never gave any problems) was:

cdusb.exe version 3.3.4.0 20110212

Log:

=====> Passage : 1
DRIVEGETDRIVE(ALL)
Drive C: - READY - NieuwVolume
Drive D: - READY - NieuwVolume
Drive E: - NOTREADY -
Drive X: - READY - Boot
=====> Passage : 2
DRIVEGETDRIVE(ALL)
Drive C: - READY - NieuwVolume
Drive D: - READY - NieuwVolume
Drive E: - NOTREADY -
Drive X: - READY - Boot
=====> Passage : 3
DRIVEGETDRIVE(ALL)
Drive C: - READY - NieuwVolume
Drive D: - READY - NieuwVolume
Drive E: - NOTREADY -
Drive X: - READY - Boot
=====> Passage : 4
DRIVEGETDRIVE(ALL)
Drive C: - READY - NieuwVolume
Drive D: - READY - NieuwVolume
Drive E: - NOTREADY -
Drive F: - READY - Win7PE
Found CdUsb.Y, Remount drive F:
Program remount return with exit code (0=Success) : 0


The new build:

cdusb.exe version 3.3.7.21 20111130

Log:

=====> Passage : 1
DRIVEGETDRIVE(ALL)
Drive C: - READY - NieuwVolume
Drive D: - READY - Win7PE_SE
Found CdUsb.Y, Remount drive D:
Program remount return with exit code (0=Success) : 0