Weird Setup Problem: W2K SP4 is misidentified as NT or lower

  • Thread starter Thread starter Peter Stork
  • Start date Start date
P

Peter Stork

Hi,
and sorry for cross-posting - but I don't know to which of the groups
this question belongs.

Issue:
I'm running Win2000 Pro SP4, all updates installed, Windows Installer 3.1v2
installed. See version documentation at end.

I cannot install various software, since setup.exe closes after displaying
"This product cannot be installed on Microsoft Windows ME, Windows NT 4.0,
or earlier. You must upgrade your operating system to Windows 2000 or later
before installing this product."

This happens with various setup.exe, based on MSI resp. Installshield, but
most prominent those from MS Visual Studio Express (setup.exe, Version
8.0.50727.42).

I assume there is something weird in my registry or somewhere else so that
the version tests of setup.exe fail.

What exactly are the tests that setup resp. MSI does before that message is
displayed??
Can Setup be tricked into a lower version by some registry switches which
are now causing trouble?
Can I force an install by an override-option?

Any help is appreciated!
Regards, Peter


Environment variable OS = Windows_NT
Registry Keys:
HKLM\System\CurrentControlSet\Control\Windows\CSDReleaseType = 0x2
HKLM\System\CurrentControlSet\Control\Windows\CSDVersion = 0x400
HKLM\System\CurrentControlSet\Control\ProductOptions\ProductType = "WinNT"

MSinfo displays: Microsoft Windows 2000 Professional, Version: 5.02195
Service Pack 4 Build 2195
 
Can you set the msi logging policy
(http://support.microsoft.com/kb/q223300/) to verbose and retry. You'll
get a log file in your %TEMP% folder that will list the various OS
properties that your setup is using to erroneously determine whether to
prevent the installer from continuing. In particular You're looking for
the 'Version9x' and 'VersionNt' properties listed at the end of the
file.
 
Unfortunately there is no log file written -
although msi.dll is the first dll loaded by setup.exe (as I can see using a
file access monitor). I double checked the registry entry be installing an
..msi-file - the log was created. It seems that this registry key has the
same effect as giving a command line option to msiexec.

If I had a .msi file which was explicitly designed to install on W2K SP4, XP
and higher only, I might be able to reproduce the issue and then trace it.
How could I get such an .msi?

Another idea:
I have scanned the registry access and file access, and found a huge amount
of checking against
HKLM\System\CurrentControlSet\Control\Session
Manager\AppCompatibility\Setup.exe
and a huge amount of file checks against various files. Any chance that
there is a wrong AppCompatibility around?
 
Peter Stork said:
Unfortunately there is no log file written -
Click to expand...

If you are starting via setup.exe this exe might also specify logging
options, like a different log file name and location. Maybe you can find it.

You could try running the setup with /a for administrative install. This
should unpack the files (including the .msi file) to a location you specify.
Or start the setup as usual and while the first dialog is on the screen look
for the extracted .msi file in the temp folder or in C:\Windows\Downloaded
Installations. Once you have the .msi file you can run it directly to make
sure it uses your own logging options. This would also enable you to open
the .msi file (with Orca) to look at the LaunchCondition table entries.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)
 
The initial setup programm (for example, vbsetup.exe from visual studio
express) unpacks setup.exe plus a lot of surrounding files into a temporary
directoy (but no msi-file there), and starts setup.exe. setup.exe ignores
any command line option.
vbsetup accepts /Q (quiet), /T: for temp dir, /C for unpack only, /C:<cmd>
for override Install command.

setup.exe produces a file "msinterr.txt" in TEMP which only contains two
lines starting with "Event" - no error messages etc.
 
Hi - the mystery is partially solved.

This is NOT a problem in setup.exe, or of MSI. The problem goes away as soon
as I RENAME setup.exe to something different (e.g. mysetup.exe)! I have
checked with three different setup.exe files from different products. All
failed with an error message indicated wrong version of Windows, and worked
when renamed.

I did the final test: I took a simple program that displays Windows Version
(using GetVersionEx Call). That worked fine. When I renamed it to setup.exe,
it displayed : Windows NT 4.0, Service Pack 5, Build 1381 !!! BINGO!

This proves that it has something to do with "Application Compatibility"
settings - So that is a completely different ball game. Though I have
removed all entries in HKLM\System\CurrentControlSet\Control\Session
Manager\AppCompatibility\setup.exe, the effect does not go away.

So: Where to look for "application compatibility" keys and settings??

Thanks to all who helped so far!
 
Hi,
here is the full solution (go up the news thread for situation - W2K, SP4,
setup.exe "sees" WinNT 4 SP5).

So, obviously that registry key
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\XXX.YYY
can be used to set a lot of flags and modify the system behaviour everytime
a File image XXX.YYY is loaded.

See http://blogs.msdn.com/junfeng/archive/2004/04/28/121871.aspx for the
next to comprehensive source I have found about that registry key. There is
something about that key in the MS KB, but it does not cover all possible
subkeys (e.g. nothing on ApplicationGoo).

It applies to ALL images XXX.YYY - at ALL TIMES. No check for pathname or
other attributes is done. In my case it applied to all images "setup.exe"
(and there are other names under that key, i.e. "install.exe", "game.exe"
etc..).
That generates uncontrollable side effects (imagine how many files
"setup.exe", "install.exe" are around!!) and is absolutely worst programming
practice. It looks like an internal hack by Microsoft - probably that is why
it is so badly documented.

Now to the Subkey "ApplicationGoo". This one is for Application
Compatibility. It obviously can set
a) Operating System Version, Service Pack etc. which is then simulated to
the ImageFile XXX.YYY
b) maybe also set Version Information displayed by the application itself
(??)

ApplicationGoo bypasses / overrides the "Windows Application Compatibility"
settings which you can set using the Application Compatibility Toolkit resp.
Compatibility Administrator Tool (see below) and which are stored in
HKLM\System\CurrentControlSet\Control\CurrentVersion\Session
Manager\AppCompatibility\XXX.YYY resp. in the corresponding *.sdb
databases.
It is not displayed/analyzed by Compatibility Administrator. Since its
functionality could be safely and in a documented manner achieved by the
Compatibility Administrator, this again proves it is a Microsoft hack (also
the name indicates that).

The format of the value string of ApplicationGoo varies. In my case (with
setup.exe), I could clearly identify a) Major System release 4 (for NT 4.0),
Build 1381 (hex 0x0565), SP 5, and a String saying "Service Pack 5". So the
result was that "WinNT 4.0, SP 5" Version information was mimicked to all my
setup.exe images. Other entries with ApplicationGoo have different formats
with much more data, but all contain a string with "version" or something
like that.
When I deleted that key for "setup.exe", the behaviour of my setup-files
returned to normal.

For the "Microsoft Windows Application Compatibility Toolkit":
Search microsoft.com for explanation, it is an official well documented
feature. Unfortunately, MS has broken all the links on MS.com to the
"Application Compatibility Toolkit 3.0" (act30pkg.exe) - which is the last
version which works for W2K SP3 and SP4. I was finally able to download it
from
http://safariexamples.informit.com/...cation Compatibility Toolkit 3.0/act30pkg.exe

Regards, Peter
 
Another thing that can produce this behavior is an entry for setup.exe in
HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths.
 
Back
Top