I do not use anything else, I slipstreamer the updates for the OS is up to date. But no other scripts or tweak. In task manager i see find.exe ! I kill it three times and OOBE.cmd continue...
I am guessing that the updates are integrated into the install.wim before OS installation? Such as using the Simplix pack? I am unsure why it is failing as I know @Enthousiast uses the Simplix pack to update his Win 7 iso's and then tests with the project for me, not had any problems as such before, (only the once which was quoted earlier). I know for sure that the 'Find.exe' command is not used within the early stage of the project as it has limitations which the newer 'findStr.exe' command does not. The 'findstr.exe' command is used in the 'Add-On Manager' - which is run after you have entered the username etc so it is way past the initial setup stages. When i get time i will take a closer look into the early stages of MRP even decompile.exe itself. It seems it is a rare event which makes it very hard to pinpoint.
I do not use a pack I integrate updates myself with DISM or Powershell cmdlets I can reproduce it systematically now. Knowing that I am using an unattend.xml response file that passes all the OOBE steps including the name seizure wizard. If I can help debug this point it is with pleasure.
Some people have had a few problems with using (Auto)Unattend.xml files with MRP , not sure why, as technically it should work together. If the xml has x86 and x64 sections within the same file i have heard it can cause some glitches. Maybe separate them into one xml for x86 and another for x64 installs - if it still fails then it may be a certain line in the wrong place or something. Does MRP install ok if no (Auto)unattend.xml is used - if so then it does point to something within the xml that is causing the problem... Sadly i cannot help much on that side as it is not part of the project, plus last time i (attempted to) use autounattend files was in the Vista days.
What exactly do you put in the $OEM$ folder or inside install.wim\sources\setup\scripts? And what xml file do you exactly use (content)?
I was asked about allowing Spotlight features to work, I am working on this but it may not work as expected due to other factors/options used within MRP. Blocking of OS Adverts and Setting Metered connections can affect Spotlight functions. It seems Spotlight is easy broken even without MRP's help, you can read the stories about this if you Google search! If i cannot find a way to allow this, then it cannot be done and i will not spend any more time on the matter, sorry.
@cerede2000 I can't see anything out the ordinary with your xml, however the value of 1 for Horiz and Vert resolution is surely invalid? , i always used horiz:1024 x Vert:768 (as at that time my monitor was a old crt type). I did find the 'FIND' command in one section for checking EditionCBS etc and changed it now to 'findSTR /i' and did a test install, it does not affect the result, but was the only FIND reference! Have you tried the QT 94 ? as that uses the same routine with FIND in (changed that too now for v95.0), if that too hangs then that confirms the above EditionCBS routine caused the problem.
Hi, the value of 1 for Horiz and Vert resolution is a trick for autodetect I use FirstOfMay_M112.0BL_Compiled_30th_Apr_2019.7z and i've FIND.exe bug Where download 95.0 ? I don't see link in second post.
ah i always wondered how windows auto detected screen res. see its been a while and i not remember those things, there again my memory is a bit strange at the moment anyway I am still finishing off QT v95.0 QT 94 is still available, this still uses the FIND command. It may or may not hang on your installed system. If it does then the area where FIND is will be the culprit and i have changed things a bit on MRP v114 (still in testing) and QT v95 (still testing).
Appears the rare 'FIND.exe' bug has been fixed MRP 114 - RC5 is getting close now. QT 95 will be very soon too. Just a few little bits to sort out.