Tripredacus Posted October 12, 2009 Share Posted October 12, 2009 This is in referral to this project:http://www.msfn.org/board/imagex-hta-win-p...64-t138048.htmlI have determined that VBScript processing is not happening at all in Win PE 3.0 x64. The HTA itself is working fine except you can't do anything with it. None of the functions that require VBScript will work properly. Is there perhaps a file missing that I need? For example, running this function (its launched by clicking an image link) does nothing at all:Sub UnmountDim Answer Answer = window.confirm("Click OK to install Vista apps") If Answer Then objshell.run("vista_pe_selector.exe"),0 Else End IfEnd SubAnd it should create a msgBox to show an OK box. When you click OK, it runs the EXE shown there or else Cancel and it does nothing. I have recompiled the programs for x64, so its not that it can't launch the programs. Now, the following code does something different. For some reason (if I am reading the code properly), the var for myInput = 7 because the "Aborted" box shows up right away. Sub doTask(doMe)Dim myInputDim myErrorIf doMe = "1" Then MsgBox "You must select image to apply first."Else If Instr(1, doMe, "1", 1) > 0 Then myInput = 1 If myInput = 7 Then MsgBox "Aborted" Else Call DiskPart() If objFso.FileExists(Sysfolder & "\1.txt") Then objShell.Run doMe,1,True Call confirmation2() On Error Resume Next Objfso.DeleteFile(Sysfolder & "1.txt") On Error Goto 0 Else End If End if Else myError = objShell.Run(doMe, 1, True) End ifEnd ifEnd SubHowever, the link object with the following code to open the Command Prompt DOES work properly, and it still uses the doTask sub.onclick=doTask('%comspec%')So what could be the reason that VBScript is not functioning in this PE?Edit: I forgot to add that I have tried the following as well. Each of them succeed but offer no change.x:\windows\system32\regsvr32 vbscript.dllx:\windows\syswow64\regsvr32 vbscript.dll Link to comment Share on other sites More sharing options...
leen2 Posted October 12, 2009 Share Posted October 12, 2009 Use DISM to add the winpe-scripting package to your PE image.e.g. Dism /image:<path to your mounted image> /Add-Package /PackagePath:<path to your petools packages folder \winpe-scripting.cab>Then add the language package for it as well.e.g.Dism /image:<path to your mounted image> /Add-Package /PackagePath:<path to your petools packages\en-us folder \winpe-scripting_en-us.cab> Link to comment Share on other sites More sharing options...
Tripredacus Posted October 12, 2009 Author Share Posted October 12, 2009 Use DISM to add the winpe-scripting package to your PE image.If you see my referral link, this was already done. Link to comment Share on other sites More sharing options...
Yzöwl Posted October 12, 2009 Share Posted October 12, 2009 Silly question I know but ObjFSO and ObjShell are Set elsewhere in the script are they? Link to comment Share on other sites More sharing options...
Atheros Posted October 13, 2009 Share Posted October 13, 2009 try installing the language pack thats in the winpe_fps\en-us folder for the scripting package to see if that lets it work... i use winpe amd64 as a recovery source and letting you know it works fine. so defo something being missed.... also the exe application has to be 100% 64-bit as they WOW function doesnt work in winpe.just remember to copy mshta.exe from the system32 folder to the syswow folder as they still haven't corrected this bug. (but you seem to already have your hta running so you prolly dont have to do this)hope this helps Link to comment Share on other sites More sharing options...
Tripredacus Posted October 13, 2009 Author Share Posted October 13, 2009 Silly question I know but ObjFSO and ObjShell are Set elsewhere in the script are they?Yes it is.Set objShell = CreateObject("WScript.Shell")Set objFso = CreateObject("Scripting.FileSystemObject")Original source located here, v71: http://www.msfn.org/board/winpe-2-0-gimage...tml#entry652594 Link to comment Share on other sites More sharing options...
Atheros Posted October 15, 2009 Share Posted October 15, 2009 (edited) If objFso.FileExists(Sysfolder & "\1.txt") Theni think you'll find that it will always return a negative result until you remove the "\"corrected code: If objFso.FileExists(Sysfolder & "1.txt") Thenalso as i said before: sysfolder = syswow64 in 64-bit so your text file must reside therehas this solved it? or am i being an id***? Edited October 15, 2009 by Atheros Link to comment Share on other sites More sharing options...
Tripredacus Posted October 15, 2009 Author Share Posted October 15, 2009 Sorry Atheros. Currently I am not going at it on my own (or with help from people here) yet as I have an SR open with Microsoft about it.But ok, so the sysfolder, is defined here:Set SysFolder = Objfso.GetSpecialFolder(1)But yes, looking at this code, you may be on the right track! Because obviously the code after this, which sets the dimensions of the HTA, does in fact work... So is this "GetSpecialFolder" a global variable? It isn't defined anywhere in the HTA. So I am understanding that when it looks at SysFolder in x64, the PE returns Syswow64, instead of System32. How can it be (easily) changed to return System32?Update:Nope this is a dead end, going after SysFolder. I got this code written up real quick, to find out what variable is being returned:Dim fso, tempfile, tfolder, tname, tfileSet fso = CreateObject("Scripting.FileSystemObject")Set tfolder = fso.GetSpecialFolder(1)MsgBox(tfolder)Saved as test.vbs, and executed as cscript test.vbs. The messagebox that comes up says: X:\Windows\System32So this object isn't referring to syswow64. There must still be something missing. I was hoping it would have been that simple! Link to comment Share on other sites More sharing options...
Atheros Posted October 16, 2009 Share Posted October 16, 2009 (edited) odd because when i was testing the code it was pointing to my syswow64 folder (vistax64). i ran your script and yest it does seem to return system32 folder. also the \1.txt = root\1.txt thats why i said to remove the "\". so it calls systemfolder\1.txt. check it out, this is the code i used and although the variable is calling system32 folder, it fails even though the file is in system32, but if you put the file in syswow64 it returns with the working value. Sub Window_OnloadDim fso, tempfile, tfolder, tname, tfileSet fso = CreateObject("Scripting.FileSystemObject")Set tfolder = fso.GetSpecialFolder(1)MsgBox(tfolder)Set objfso = CreateObject("Scripting.FileSystemObject")If objFso.FileExists(Sysfolder & "1.txt") Thenmsgbox "moo"elsemsgbox "baa"end ifEnd Sub Edited October 16, 2009 by Atheros Link to comment Share on other sites More sharing options...
Tripredacus Posted October 16, 2009 Author Share Posted October 16, 2009 OK I am starting to think we can make this easier. I don't think we have to worry about sysfolder. There is another sub that controls applying the images. See this snippet:If Radio.Checked = True ThenmyInput2 = window.confirm("Would you like to apply the selected image?") If myInput2 = false Then MsgBox "Aborted" Exit SubSo if I choose to apply an image, it needs to get a var back from window.confirm. Since we have already established that window.confirm isn't working, this value would be "false" thus generating the "aborted" message. So if there is a way to simply replace window.confirm, this may solve this problem.Update: Another user confirmed that window.confirm does not work in the x86 version either. I have safely replaced that code, here is a new example:Dim Answer, objShell, objFsoSet objShell = CreateObject("WScript.Shell")Set objFso = CreateObject("Scripting.FileSystemObject") Answer = MsgBox("Do you want to install XP Apps?",1,"XPapps") If Answer Then objshell.run("xp_pe_selector.exe"),0 Else End IfSo the new PE must have something that was changed from last version. Perhaps the Cscript program was changed? We may never know. Link to comment Share on other sites More sharing options...
Atheros Posted October 17, 2009 Share Posted October 17, 2009 yes i noticed it too. i could no long do answers unless i specified the true valueforgive me as this is prolly gonna be messy.sub startbutton_OnClickblnanswer "do you want to install XP apps" if blnanswer = "true" then diskpart if blnanswer = "false" then exit sub'next function if truemsgbox "About to deploy image, a window will popup to confirm when the process is complete. this can take upto 30 mins"set objapp = createobject(wscript.shell")objapp.run "imagex /apply" & " %path%\%imagename%" & " %index%" & " %pathtodeploy%",0,trueblnanswer "image apply complete, would you like to reboot now?" if blnanswer = "true" then shutdown if blnanswer = "false" then exit subend subsub diskpartset objapp = createobject("wscript.shell")objapp.run "diskpart /s script.txt",0,true 'hides that **** command prompt windowend subsub shutdownset objapp = createobject("wscript.shell")objapp.run "wpeutil -reboot",0,trueend subproblem is from there it will process that sub and continue down the original sub so i had to stop it by using the exit sub command if the value was false. Link to comment Share on other sites More sharing options...
Tripredacus Posted October 19, 2009 Author Share Posted October 19, 2009 Yes, I see you added the true/false in there. My example does not have it, so in some cases (such as using it to shutdown the pc) it executes the following code no matter what. I'd hope that other people would have seen that! I have not made the code change to fix that issue yet. Maybe tomorrow! Anyways, since I did take this issue to Microsoft, and yet fixed it myself. Although Atheros led me on the track that the same code brought different results, and tabone confirmed that some code doesn't work anymore. I ended up changing my SR to a bug report, at least for window.confirm. Thanks everyone for your help!Ohh Atheros, my use of installing apps, XP or Vista, is an option that is called after applying an image. A lot less logic required for that. I haven't posted that code yet but maybe one of these days I will! Link to comment Share on other sites More sharing options...
Atheros Posted October 19, 2009 Share Posted October 19, 2009 (edited) ok so i couldn't find your issue using my winpe, but now i have made one from scratch, and window.confirm most definetly isn't working.im gonna look into it as MS don't respond easily, as i need this function also. you could use the winpe built on the windows disk as this works fine (install.wim 1 \windows\system32\recovery\winre.wim..... until we see whats really going wrong or find a fix.[EDIT] OK GOT IT WORKING [/EDIT]OPEN DEPLOYMENT TOOLS COMMAND PROMPTCOPYPE AMD64 C:\WINPEIMAGEX /MOUNTRW WINPE.WIM 1 MOUNTDISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-HTA.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-MDAC.CAB.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-SCRIPTING.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-WDS-TOOLS.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\WINPE-WMI.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\LP_EN-US.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-HTA_EN-US.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-MDAC_EN-US.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-SCRIPTING_EN-US.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-WDS-TOOLS_EN-US.CAB"DISM /IMAGE:MOUNT /ADD-PACKAGE /PACKAGEPATH:"C:\PROGRAM FILES\WINDOWS OPK\TOOLS\PETOOLS\AMD64\WINPE_FPS\EN-US\WINPE-WMI_EN-US.CAB"XCOPY MOUNT\WINDOWS\SYSTEM32\MSHTA.EXE MOUNT\WINDOWS\SYSWOW64IMAGEX /UNMOUNT MOUNT /COMMITNow that is everything exactly what i have done to the letter no deviations, nothing. and its working....give it a go Edited October 19, 2009 by Atheros Link to comment Share on other sites More sharing options...
Tripredacus Posted October 19, 2009 Author Share Posted October 19, 2009 So the only main difference is that you added the en-us packages and copied mshta to syswow64. And now Window.confirm works? Ah I would go this route too if I didn't fix it in another way. Link to comment Share on other sites More sharing options...
Tripredacus Posted October 20, 2009 Author Share Posted October 20, 2009 Its no big secret Atheros. I already posted it above. This only fixes the window.confirm by replacing it with MsgBox. After my research, it seems that window.confirm is a Javascript leftover and isn't documented for VBScript at all. Here is a now fixed, and working example:Sub AppendDim Answer Answer = MsgBox("Do you want to install XP Apps?",1,"XPapps") If Answer = 1 Then objshell.run("xp_pe_selector.exe"),0 Else Exit Sub End IfEnd SubSo to be creative, replacing other parts, such as the peice that is called when you select a radio button for an image:A snippet from the beginning of showRadioInfo()myInput2 = MsgBox("Would you like to apply the selected image?",1,"showRadioInfo") If myInput2 = false Then MsgBox "Aborted" Exit Sub Else Call DiskPart()And later onIf RebootAfterImageApply = 0 Then Answer2 = MsgBox("Image applied successfully!"& Chr(13) + Chr(13) & "Click OK to Shutdown?",1,"SUCCESS") If Answer2 = 1 Then objshell.run("wpeutil Shutdown"),0 Else Exit Sub End IfOn my HTA, i did not replace all instances of window.confirm. For example, we do not make use of mounting any wims and capturing/appending images are not the task of the regular software deployment people. There was a time, back when we used Ghost, we let anyone save images. What ended up happening is having tons of images with ambiguous names. If I handle all image management myself, I can confirm that everything follows a naming convention and is easy to find and sorted properly. Instead of relying on people who might have been too lazy to name the images properly. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now