WindowsPE CLI not working
zathorian opened this issue · comments
Hi,
Thanks for the tool!
When using the tool (recent version) in CLI mode in Windows PE (ADK 1803) it does create the file, however the values are not added (please see attached file
key.txt
).
It does show all information when running in GUI mode, however unlike in Windows 10 it needs several seconds to show the values (I do see a spinning circle first which I do not get in Windows 10). Therefore I suspect a timing issue that in CLI mode the file is written too soon.
I do have tried also the older version and either it does not run on PE at all or it has the same behaviour.
Thanks again,
Zathorian
Thanx Zathorian
CLI mode has largely been untested in WinPE.
I agree, most likely a threading issue (the spinner should not be visible in CLI mode at all.)
I will look into this and report back.
Thanx for your feedback.
Thanks, looking forward! If you need me to test anything or to provide mor information, I am happy to help.
Btw my text was mistakable. I do see the spinner only in Windows PE and only in GUI mode. The CLI mode is without any GUI element as it should be. However in Windows 10 I do not get the spinner in GUI mode which has lead to my assumption that maybe that delay with the spinner is causing the threading/timing issue.
Thanks for the new version. I tested it in Windows PE with these results:
- the new help switch does work
- the GUI does work = show the OEM key
- the CLI output is now even shorter (sample output) = does not work as expected yet
Thanx for this, much appreciated.
I don't have a working WinPE test environment yet.
I just did some code clean-up (switching GUI dependencies etc) - I will let you know when I get it working my side ;)
Cheers.
Ok, thanks again. Not sure if the license does allow to upload a PE ISO here (likely not), so if you need any information how to create a WinPE disk/iso, I am looking forward to provide you those.
One last result from my side before I wait for the new version.
When using WinPE with a hardware which has no OS installed yet (=blank disk - my tests before have always been done with a preinstalled Windows 10) I do get this error in CLI mode:
Interestingly I do get then a file which contains the proper OEM license key! (replaced in the upload by XXXXX)
key.txt
In GUI mode I do get:
@zathorian
Thanx, I have set up WinPE - I wanted it as basic as possible ( only cmd, notepad and NetFx)
I note saving the text file from the GUI gives a ClassID error - this is related to lack of explorer.exe - I will need to handle that exception - any ideas? Default to X:\ or prompt for manual path?
@bessonniy
Thanx, noted.
For me it does not matter really where the GUI file is written to as long as it would work.
X:\ would be fine by default, however I do not know if all WinPE editions will mount as X (I assume they should). So maybe use an environment variable like %SystemDrive% or %TEMP% instead. Or maybe better - default to the location the exe is located as the user should always know where that file is as he is calling it. Handle the file save / IO exceptions (e.g. if called from a mapped network share without write access) and use then %TEMP%.
Thanks and sorry for the late reply. I was afk during the weekend.
I tested the new build with these results (all from within WinPE):
- OS not installed (did a "format c: /q"), CLI mode, no OEM license (VirtualBox VM):
If I then select Yes:
If No in the screen before (or OK here):
I would not expect that the CLI mode opens any GUI elements at all. It should directly select "no" internally". Also it does not return the prompt in the last screen (I do have to press a button).
It does write a output file, but it contains label/placeholder texts
key.txt - Same setup as above, but without a CLI parameter:
Shows also the first screen from above. If I select No it closes itself, if I select Yes (after the error from above) I do get:
- OS installed, GUI mode, OEM license available:
Does work as expected, "Save" button does work (and message where it is saved, great!) - OS installed, CLI mode, OEM license available:
Does also work, saved file is fine. It does wait again as above to press a key to release the prompt - Same as above, but wiped the disk with "format c: /q":
No output or GUI or error message at all. No file is written also.
It is making good progress, but it is not there yet. Thanks again!
If you need anything else tested, I am glad to help.
Thanx @zathorian
Good to see the initial test went well - I did not code/test for without an installed Windows OS.
TODO:
- Per screenshot 1 above
- Check for CLI mode when no OS installed.
- Change Yes/No to OK button which closes the app. if no OS and no OEM found (We can't search without Windows present)
- if OEM found - OK button saves txt file to StartupPath (as per current beta)
- The missing object reference in question is the Offreg.dll - change to only extract when OS present.
I'm winging it here as PE is new to me (not the easiest to debug on, gotta say) - please let me know if I'm missing anything.
Yes, that summarizes it quite well. However here are the points in my words (sorted by priority):
- the "no OS" found mode in WinPE needs to be fixed for both GUI and CLI to provide a proper output. This is a "must have" as for new OS deployments the disks are in most cases empty (in my use case at least).
- in CLI mode it should never show a GUI element - also no error message as popup, only with console.writeline() if needed (does not matter if OS or OEM is available or not). CLI and GUI elements exclude each other in my eyes. Also a "must have" as all popups do block a script from running. When you do have the goal e.g. to extract the OEM key and set it later-on during deployment an unattended run is the one I am aiming for.
- in CLI mode it should not wait at the end to press a button (remove Console.ReadLine() or whatever is blocking the prompt after everything has been done). Nice to have (see "start /wait" below).
- in CLI mode it should not release the prompt before it is finished (see screenshot 3 above where you do see the prompt after the program has been called in CLI). This is a "nice to have" as with e.g. "start /wait showkeyplus.exe key.txt" you can wait till everything is done. However other command like "copy" also do not release the prompt in-between (= I cannot write new commands in the same CMD window while the copy process is running)
- Minor change request: Expand "file saved as key.txt" to the full path e.g. "file saved as x:\key.txt"
Thanks!
New Beta with some fixes.
Re: CLI file saved as "key.txt" to the full path
The full file path will be shown if it is explicit in the command.
Eg. this command...
C:>ShowKeyPlus.exe C:\Users\Craig\source\repos\ShowKey\bin\x64\Debug\Key.txt.
returns this...
C:>File saved as C:\Users\Craig\source\repos\ShowKey\bin\x64\Debug\Key.txt.
Test results based on the recent version (as always from within WinPE only):
-
no OS installed, with or without OEM license available, CLI mode:
it does work! 👍
If the OEM license is available I do get this as output
Auto-discovery did not find any Windows installation
OEM information found
If the OEM license is not available, that complete block incl. the "OS not found message" is not shown.
This is for sure a minor thing. -
OS installed, OEM license available, GUI mode:
everything does work! 👍 -
OS installed, OEM license available, CLI mode:
output file is written properly, the process does NOT close itself anymore when using "start /wait showkexyplus.exe key.txt" as in the release before. I do have to press "CTRL+C" after "file saved as key.txt" does show up. -
no OS installed, no OEM license available, GUI mode:
if I click on "OK" it closes itself (not sure if it should do that, if yes, it does also work).
Bottom line, very good progress.
For me the one remaining priority issue is that it does not close itself anymore if an OS is found in CLI mode. Worst case I would have to write something in my wrapper script that it will be killed after some time but I would like to avoid that if possible.
Thanx for the feedback. Good work ;)
The interaction with Console is problematic as cmd.exe seems to have very set parameters within which it operates, but I want to get that working.
As part of the refactoring process I will try some other methods to make it as seamless as possible.
I appreciate your input.
I implemented a powershell wrapper in the way that I do NOT wait till the process closes. instead every now and then I check if the file has been written properly. That way it does work, however it is not ideal.
Positive aspect is that this way it is working 100% fine for my use case 👍 currently more extensive tests are running. I do not expect any new issues though. Thanks!
That's excellent!
I will close this as an issue and consider the oustandings as enhancements for a later release.
I usually release a new version with each Windows RTM release - although I don't see any new Windows editions or API breakages we need to cater for in the May 2019 Update...)
Thanx for your support.