[wpkg-users] [Bug 287] New: Intermittent problem Uninstall not found in System Context

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Bug ID: 287
Summary: Intermittent problem Uninstall not found in System
Context
Product: WPKG
Version: other
Hardware: PC
OS: other
Status: NEW
Severity: major
Priority: P2
Component: wpkg.js
Assignee: ***@wpkg.org
Reporter: ***@grrl.lib.mn.us
QA Contact: wpkg-***@lists.wpkg.org

When running WPKG via Deep Freeze Maintenance mode (System Context executing
WPKG.js) we occasionally have PC's that will fail the "uninstall" check
condition. After checking for the valid registry file we can verify that it
does exist. If we run WPKG.js manually then the check will work properly which
seems to eliminate the possibility of syntax errors and typos.

Is this a known issue to your knowledge or is there any way to troubleshoot
this more accurately?

Thank you,
~Rob

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #1 from Robl <***@grrl.lib.mn.us> ---
One further observation;

This only seems to affect the uninstall check of programs under the
"HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" location. We have
not seen any failures of this check for programs located in the
"HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
location. I'm not sure if this is relevant or not.

System information:
Dell Optiplex 5040
Windows 7 x64 Enterprise

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Rainer Meier <***@wpkg.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@wpkg.org

--- Comment #2 from Rainer Meier <***@wpkg.org> ---
Well, this often happens for custom installers which fork their own
installation process and the initial process terminates. You can usually run
such installers from command-line with silent options and you will be returned
to the prompt before the actual installation is finished.

Of course for WPKG it will run the uninstall checks right after the process it
launched terminated. In case of installers which fork installation processes
the uninstall entry might be written with some delay.

This is not a bug in WPKG but rather an issue (known) with broken silent
installers. The same even more frequently applies to uninstallers.


There are several ways to deal with such broken installers:
You might simply write a small wrapper script (e.g. a cmd shell script) which
launches the installer and waits for it to complete. Either by using a
hard-coded timeout (not recommended as installation time might vary a lot
depending on various circumstances) or by repeatedly checking for the installer
to finish its work. This check might be a check for a file created by the
installer or even the uninstall entry itself to appear. The key is that this
wrapper script should not terminate except in timeout case or if the installer
completed its job.

There is no general recipe working for any installer out there, it depends on
the specific program how such a wait function could look like.

For the time being try a shell script as follows:

@echo off
start /wait path\to\installer.exe /silent-options [...]
ping -n 600 localhost > NUL
exit 0

This will wait 10 minutes after launchning the installer. You might extend this
by a loop and file/registry checks rather than hard-coded wait time.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Rainer Meier <***@wpkg.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|major |minor

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #3 from Robl <***@grrl.lib.mn.us> ---
Rainer,

Thank you for the response. Perhaps I am not fully understanding something but
I don't think we are on the same page. The installer works properly but the
check isn't succeeding, even if I installed the application many weeks ago,
once the check initiates it's almost as if it does not "see" the registry
entry. In order for me to make it work and properly run the check I need to
manually launch the batch file that starts up the wpkg.js.

Are we talking about the same thing and I'm just not understanding?

Thank you!

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #4 from Rainer Meier <***@wpkg.org> ---
OK, if you still don't see the entry even after a while but you can see it from
your user account and it's in HKLM tree of the registry then there are two
possibilities:

- you are running WPKG with 32-bit cscript.exe
- the process running WPKG does not have read permissions on the uninstall key

The first option is quite a common one. If WPKG is executed from 32-bit
environment (e.g. 32-bit WPKG client or any other 32-bit launcher) then Windows
will launch 32-bit cscript.exe. As a result wpkg.js will not be able to read
the 64-bit uninstall entries!

If you are unsure whether you run WPKG from a 32-bit or 64-bit process try
launching wrapper.js (included in WPKG distribution) instead of wpkg.js
directly. It will assure WPKG is run from 64-bit csript.exe.

You can also try to run wpkg via %SystemRoot%\sysnative\cscript.exe.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #5 from Robl <***@grrl.lib.mn.us> ---
Rainer,

Thank you so much for the quick responses. So I kind of thought it may be
something like this so what we tried to do was change the way our batch file
executed wpkg.js. I have included what that file looks like:

echo %DATE% %TIME% > c:\temp\maint_status.log 2>&1
whoami >> c:\temp\maint_status.log 2>>&1
echo %PROCESSOR_ARCHITECTURE% >> c:\temp\maint_status.log 2>>&1

%windir%\SysWOW64\cscript.exe /b /nologo \\DOMAIN\wpkg\wpkg.js /synchronize
/quiet /nonotify /noreboot >> c:\temp\maint_status.log 2>>&1
whoami >> c:\temp\maint_status.log 2>>&1

So we believe we are executing the 64bit cscript.exe (previously it had been
%windir%\System32\cscript.exe). I have never used %Systemroot%\sysnative\ but
it seems to return path not found for me.

With that being said can I use the same command above to execute the wrapper.js
instead of the wpkg.js without problems?

As for the second point about permissions; Do you know how I would check if
this is the case, when WPKG runs the check on the registry files doesn't this
happen under the Local System context? I would imagine it having permissions to
the HKLM registry hive, but admittedly haven't done any looking at this.

Thanks again!

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Marco <***@fgcz.ethz.ch> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@fgcz.ethz.ch

--- Comment #6 from Marco <***@fgcz.ethz.ch> ---
%windir%\SysWOW64 is the path for the 32-bit binaries on windows.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #7 from Robl <***@grrl.lib.mn.us> ---
Marco,

So then the original command "%windir%\System32\cscript.exe /b /nologo
\\DOMAIN\wpkg\wpkg.js /synchronize /quiet /nonotify /noreboot" would have been
calling the x64 version of cscript.exe?

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #8 from Rainer Meier <***@wpkg.org> ---
(In reply to Robl from comment #7)

Post by b***@bugzilla.wpkg.org
So then the original command "%windir%\System32\cscript.exe /b /nologo
\\DOMAIN\wpkg\wpkg.js /synchronize /quiet /nonotify /noreboot" would have
been calling the x64 version of cscript.exe?

Yes it does. Unless called from 32-bit cmd.exe which would force it to be
redirected to SysWoW64\cscript.exe and therefore execute 32-bit cscirpt.exe
again.

So just use "%windir%\System32\cscript.exe /b /nologo \\DOMAIN\wpkg\wpkg.js
/synchronize /quiet /nonotify /noreboot" but absolutely make sure it's run from
64-bit cmd.exe.

If in doubt call %SystemRoot%\sysnative\cscript.exe (if it exists, which is the
case on 64-bit systems only). This is what wrapper.js does. It fixes the
mistake of users running cscript.exe from a 32-bit application and forces to
invoke 64-bit cscript.exe.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #9 from Robl <***@grrl.lib.mn.us> ---
Rainer,

Okay I think I understand now. So basically I have this going on:

Deep Freeze's Batch program (Built into the software somehow) is triggered
which then triggers a batch file which then triggers wpkg.js. Even if I use
64bit version of cscript it will run in 32 bit because it is being opened using
a 32bit cmd program, which even if it was launched in 64bit mode, it would also
be converted to 32bit since it's highly likely that Deep Freezes "Batch
Launcher" is also in 32bit mode.

So in order to stop this chain I can use %windir%\SysWOW64\cscript.exe /b
/nologo \\DOMAIN\wpkg\wrapper.js which will then choose the proper mode in
which to launch wpkg.js and will override the architecture it was launched in
and just pick the correct version.

Is this correct?

That being said I'm a little curious as to why this actually doesn't work when
running 32bit cscript? When I dug into the wpkg.js a little bit to try
troubleshooting it looks as if the uninstall check uses the scanUninstallKeys
function which is suppose to determine which registry hive it's searching
through. This check relies on a function called is64bit() which is then reliant
on getArchitecture which should be looking at the processor_architecture.

So regardless of what the architecture of the launching programs is shouldn't
it still check that Registry Hive for the sole reason that the processor is
64bit? I know I have to be missing something but this is the first time I've
had to look into this.

Thank you for all the help and enlightenment!

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Post by b***@bugzilla.wpkg.org
So in order to stop this chain I can use %windir%\SysWOW64\cscript.exe /b
/nologo \\DOMAIN\wpkg\wrapper.js which will then choose the proper mode in
which to launch wpkg.js and will override the architecture it was launched
in and just pick the correct version.
Is this correct?

NO. This is NOT correct.
Launching %windir%\SysWOW64\cscript.exe will forcybly launch the 32-bit
version. Remember: SysWoW64 always contains 32-bit binaries!

So you need to launch %windir%\system32\cscript.exe. But Remember this will
ONLY work if your launching process is a 64-bit process as if the launcher is
32-bit it will get redirected from system32 to syswow64 which will trigger the
32-bit version again.

You can try this by launching syswow64\cmd.exe. Then "cd" into
c:\windows\system32 and you will be redirected to c:\windows\syswow64. There is
no way for 32-bit applications to access the real system32 folder with 64-bit
binaries in it as the folder is invisible and redirected to syswow64 for 32-bit
programs.

The only way to launch a 64-bit binary from the real system32 folder is to open
it via sysnative folder. So if you're inside a 32-bit program and want to
launch something from the real system32 folder you need to launch
%windir%\sysnative\cscript.exe.

Post by b***@bugzilla.wpkg.org
That being said I'm a little curious as to why this actually doesn't work
when running 32bit cscript? When I dug into the wpkg.js a little bit to try
troubleshooting it looks as if the uninstall check uses the
scanUninstallKeys function which is suppose to determine which registry hive
it's searching through. This check relies on a function called is64bit()
which is then reliant on getArchitecture which should be looking at the
processor_architecture.

Remember that wpkg.js runs inside some interpreter "virtual machine". If this
interpreter is 32-bit there is no way for the script (wpkg.js) to access any
64-bit resources. Even if the detection is able to detect that the CPU
architecture and even OS architecture is 64-bit the 32-bit cscript.exe runtime
will suffer from the same forced redirection as any 32-bit process. So
accessing the 64-bit registry keys or system32 folder you will be redirected to
the corresponding 32-bit folders!

So when you access HKLM uninstall keys (64-bit) you will be redirected to
32-bit keys and you won't see anything in there except 32-bit applications.

The same applies for %ProgramFiles% and %ProgramFiles(x86)% with some slight
differences in access redirection.

So again, you NEED TO MAKE SURE TO RUN wpkg.js WITHIN 64-bit cscript.exe!
Else it won't be able to access any 64-bit resources. This is intentional and
by design (Microsoft). Blame microsoft for the complex redirection issues which
already caused a lot of confusion. Just remember that any 32-bit appliction
will not see the real contents here and there but being redirected to 32-bit
equivalents. This actually hides 64-bit structures from 32-bit applications
entirely. So There is nothing WPKG can do to access those resources.

If you'reunsure then change the script to launch wrapper.js rather than wpkg.js
directly. wrapper.js will ensure to launch wpkg.js in 64-bit cscript.exe even
if wrapper.js itself is launched from 32-bit cscript.exe.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Post by b***@bugzilla.wpkg.org
NO. This is NOT correct.
Launching %windir%\SysWOW64\cscript.exe will forcybly launch the 32-bit >version. Remember: SysWoW64 always contains 32-bit binaries!

I understand what you're saying but are you sure that what I wrote was
incorrect? The string of code I put is opening the wrapper.js, shouldn't this

Post by b***@bugzilla.wpkg.org
If you'reunsure then change the script to launch wrapper.js rather than >wpkg.js directly. wrapper.js will ensure to launch wpkg.js in 64-bit >cscript.exe even if wrapper.js itself is launched from 32-bit cscript.exe.

Which is what I was trying to portray in the reply you said was not correct; I
just want to make sure that I'm fully understanding this since I have yet to
figure out what the wrapper.js "actually" does.

I just wanted to say thank you for everyones support on helping me figure this
out!

Thank you!!

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #12 from Rainer Meier <***@wpkg.org> ---
(In reply to Robl from comment #11)

Post by b***@bugzilla.wpkg.org
I understand what you're saying but are you sure that what I wrote was
incorrect? The string of code I put is opening the wrapper.js, shouldn't

Alright, I thin this was my reading-inability at 1am in the morning. I didn't
actually take into account you're calling wrapper.js. Actually you are right
that if you call wrapper.js it should not make any difference whether you do
this from 32-bit or 64-bit cscript.exe as wrapper.js will launch
sysnative\cscript.exe on 64-bit systems to run wpkg.js.

Though this is the absolute last thing you should do. Especially as your case
described would run the wrong cscript.exe on purpose just to fix this mistake
by wrapper.js. Moreover execution time will increase.

So you should first try to run the right cscript.exe. Especially as you already
use a wrapper cmd script which can do this easily. For example:


@echo off
set CSCRIPT=%SystemRoot%\system32\cscript.exe
if exist "%SystemRoot%\sysnative\cscript.exe" set
CSCRIPT=%SystemRoot%\sysnative\cscript.exe

start /wait "WPKG" "%CSCRIPT%" /b /nologo \\DOMAIN\wpkg\wpkg.js /synchronize
/quiet /nonotify /noreboot >> c:\temp\maint_status.log 2>>&1



That's basically all it needs on your side to assure you're running WPKG with
64-bit cscript.exe. Just if this does not work replace the call to wpkg.js with
the call to wrapper.js which will do all the selection for you.

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

--- Comment #13 from Robl <***@grrl.lib.mn.us> ---
Rainer,

Thank you very much for all of your help. Using the wrapper.js definitely
helped with the problem I was having. Also I am doing some testing using your
best practice method, so thank you very much for showing that to me.

I really appreciate all the fantastic support and knowledge from you guys!

Thanks!

[b***@bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=287

Rainer Meier <***@wpkg.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID

--- Comment #14 from Rainer Meier <***@wpkg.org> ---
No worries Robl. Glad we could help to resolve the problem.
Sorry again about some hints pointing to wrong direction and potentially
unclear guidance.

I think we can close the report here as it turned out not to be a bug in WPKG.
If you need further support also consider consulting the mailing list where you
can find support and assistance if the main wiki page does not provide
sufficient documentation your if you need help on specific topics.

Thank you
Rainer