Timing issues at boot (Y: ready?) - what can I try? [90% solved]

Now that I have some spare time, I've always wanted to try some tests on Win7PESE to see what I can change to fix some timing issues I have. I use Win7PESE, Win8PESE and Win10PESE mostly (8.1SE mostly for testing), all of these with the same "system" to mount my portablestuff.iso at boot (osfmount), then do some font install, launch bginfo and a few more things (launched from autohotkey's initial script).

Win7PESE is the only one from this list that sometimes can't get all this done in time... It's not a very big problem, sometimes a "reload this script" helps on the Autohotkey icon, sometimes a reboot is needed, then everything is usually fine.
This makes me thing that it's just a matter of a few milliseconds here are there. But I don't know where to look! 

Any ideas would be welcomed!!
 

We will need more information 

How do you start the first process and what exactly does not work?

Well, thanks for your interest in the matter...

I use a pretty much standard build, but with no apps. I use only one app script, which loads Autohotkey:

Code: [Select]

Dirmake,%target_prog%\%ProgramFolder%
FileCopy,"%ScriptDir%\files\AutoHotkey.exe","%target_prog%\%ProgramFolder%",NOWARN
Add_Shortcut,Autostart,,,,,y:\portable\autohotkey.ahk

I use this for all projects (usb based). 8/8.1/10PESE have no problems with this setup (no timing problems ever). Win7PESE needs a few reboots sometimes (or a "reload script" on the Autohotkey icon). I was just testing it this morning, and it's the same with the latest Win7PESE 20151207 release. Now, because it does work after a reboot, I think it could be a matter of milliseconds! (Of course, make and model of usb stick could also matter, but I'm using a dozen different ones now and then, this doesn't seem to be the issue).

OK, so after booting, AutoHotkey is started, and y:\portable\autohotkey.ahk is (auto-)started. I like this method a lot, because it allows me to edit this file without making a new build. I can just edit autohotkey.ahk and/or change the contents of q.iso (which is mounted as drive Q:)

The first part of Autohotkey acts as a "RunOnce" part, the rest of the file contains Hotkey definitions (eg WinNTSetup keys for installing: ctrl-sh-x, ctrl-sh-7, ctrl-sh-8, etc).
First part ("RunOnce"):
Determine 32/64 bit (check BuildLabex), determine OSFMount version to use (32/64), mount q.iso (using osfmount, started by nirsoft execmd because it's silent), loop until drive q: is available, etc., done.

OK, I'll stop there, because I think we're already "too far" into the process by now. As I'm writing this, I think maybe the autostart of AutoHotkey and its autorun file (Autohotkey.ahk) could need a little delay here or there? But I don't know where I could insert that?

Again, JFX, thanks for your interest. Maybe you know something I can try, but this "problem" is not serious enough to waste too much of your time on, I couldn't ask that of you!!!

OK, maybe I'm beginning to understand myself now, now that I'm explaining it for others 

I just did two cold reboots with the same usb.
Boot 1: Everything OK, q.iso is mounted, bginfo is taken from Q: and displayed, etc.
Shut down, reboot,
Boot 2: q.iso is not mounted. Right-click on Autohotkey icon: reload, everything OK, even bginfo displays background after all :-)

So this looks like drive(-letter) Y: is sometimes not available on time?!!! Could be it, right?
The ahk script does no checking on letter Y:, maybe I should make that check?
 [EDIT: I'll just build in a giant "Sleep,5000" pause at the top, for testing, if it's really a problem of "Y: not ready", this should give some conclusive test results!]
On the other hand: Is there a way I can "fiddle" with the default Win7PESE code, to edit this (wait for Y:?)

Thanks again...

EDIT2: Tests are looking good... Now don't tell me I should have done a "Sleep,1440000" before posting this!! 
Seriously: The sleep,5000 seems to help a lot, and doesn't even slow the boot as far as I can tell now...
EDIT3: Nope, it's not all my fault. Another boot with another usb shows there ARE some timing issues with other stuff as well, because the resolution change doesn't happen on the first try (there's normally an automatic switch from low-res to hi-res during boot). A quick reboot fixes this, however. Maybe "switch res" and "wait for Y:" are sometimes out of synch as well?

EDIT4: Normally I only use PESE on USB, but every 3 months I make a bootable DVD with data backups (anti-ransomware readonly-backup), and I noticed that there are no timing issues with DVD, which makes a lot of sense of course, because this medium is quite a bit slower, so no need to build in extra waiting time.
On the other hand: OSFMount was causing problems, because even though I needed the newer version for Win10PESE-10586 a while ago, the DVD version of my Win7PESE seems to need the older version, and doesn't work with the newer.
Very strange, because the USB version of Win7PESE has no problems with the new version.
Oh well, a lot was learned today, so I guess I have to document all of this and keep it for future reference... 

BTW: The readonly-ransomware-safe company truecrypt-data DVD I hold in my hands now (which is also bootable on any PC, thanks to Win7PESE), must be worth a small fortune...

MountPEmedia.exe should create a log file in temp dir.
If it reports a problem, maybe we can fix it somehow.

I Don't know much about AHK, but maybe something like this au3 can be added on top of your script.

Code: [Select]

while 1
IF DriveStatus("Y:") = "READY" Then ExitLoop
Sleep(500)
wend

Thank you very much, JFX!
I will test all this week, and will keep an eye on the MOuntPEMedia log!
Thanks for the code example as well. All this time I was more focused on "waiting" for the Q: drive to be ready, I guess I forgot a bit about the Y: drive (of course the Y: letter has to be remapped first, before the iso file on Y: can be mounted as Q:)
First the chicken, then the egg 
For my "wait for Q:" code, I've used a similar piece of code for years now. At least I already knew to not poll it constantly for availability, but do it with 500ms pauses. Thanks for confirming that!

 

(I'm also doing the Windows 7 "search for updates on clean install" timing test. First result is 33minutes, I'll try to do a test every day. But that's for another thread...)

We will need more information 

Well, the thread has become a bit long, but at least it looks like the problem is fixed, or on the way to be fixed.

I do find it a bit strange that this "problem" only arises on Win7PESE, not the other projects (remember, I'm using the exact same principle on all).
Maybe WinNTSetup is just so FAST! that it wants to move on to the next task too quickly, before the previous one's finished?!
 

I'm not a great coder like you, but thanks to your example, this is what would work in Autohotkey:
(tested with a usb stick, going to test in PE, without the msgbox of course.)

Code: [Select]

while 1
{
  DriveGet,isready,Status,G:
  If isready = Ready
    Break
  Sleep,500
}

Msgbox,Drive ready