[Bug 21634] ACT!2010 installer prereq check fails (Win32_OperatingSystem WMI class queried)

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Aug 18 13:52:24 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=21634


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |dotnet
                URL|http://experience.act.com/  |http://download.act.com/act
                   |                            |partners/downloads/act2010/
                   |                            |software/ACT!%20by%20Sage.e
                   |                            |xe
                 CC|                            |focht at gmx.net
            Summary|ACT!2010 installer prereq   |ACT!2010 installer prereq
                   |check fails                 |check fails
                   |                            |(Win32_OperatingSystem WMI
                   |                            |class queried)




--- Comment #1 from Anastasius Focht <focht at gmx.net>  2010-08-18 13:52:23 ---
Hello,

looks like WMI insufficiency and bad app error handling.

The faulting prerequisite tool can be run separately for testing purposes.
When the message box appears, copy the whole
"C:\\users\\yourusername\\Temp\\{some_GUID}" folder where the "prereq.exe" app
is located to a different location (gets automatically deleted after dismissing
dialog).

Example: 

--- snip ---
CreateProcessW app (null) cmdline
L"C:\\users\\focht\\Temp\\{9863B3AD-E61C-46A7-BEFC-33BBEACE435A}\\Prereq.exe
-ConfigFile=\"C:\\users\\focht\\Temp\\{9863B3AD-E61C-46A7-BEFC-33BBEACE435A}\\Plugins\\PrereqConfigOne.xml\"
-mode=s"
--- snip ---

You can omit the "-mode=s" (=silent) parameter later.

There is an xml file "PrereqConfigOne.xml" located in "Plugins" subfolder which
is used for prerequisite checks:

--- snip ---
...
 <PrereqTask HostAssembly="PrereqCommon" TypeName="CheckForCPU">
        <Severity>3</Severity>
    <MinimumCPUSpeed>600</MinimumCPUSpeed>
    <DisplayMessage>The system does not meet the minimum requirement of a
600mhz processor clock speed (note: some processors clock
differently).</DisplayMessage>
  </PrereqTask>  
  <PrereqTask HostAssembly="PrereqCommon" TypeName="CheckForRAM">
    <Severity>3</Severity>
        <MinimumRAM>520000</MinimumRAM>
    <DisplayMessage>The system does not meet the minimum requirement of 512 MB
RAM.</DisplayMessage>
  </PrereqTask>
  <PrereqTask HostAssembly="PrereqCommon" TypeName="CheckSQLStatus">
    <Severity>3</Severity>
    <DisplayMessage>TBD</DisplayMessage>
  </PrereqTask>
--- snip ---

The tasks are implemented in "Plugins/PrereqCommon.dll" assembly.
The first task "CheckForCPU" is successfully processed because the CPU speed
requirement is read from registry:

--- snip ---
000d:Call advapi32.RegOpenKeyExW(80000002,009340b8
L"HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0",00000000,00020019,0032f194)
ret=0036a5db
000d:Ret  advapi32.RegOpenKeyExW() retval=00000000 ret=0036a5db 
...
000d:Call advapi32.RegQueryValueExW(00000204,00933768
L"~MHz",00000000,0032f1c4,0032f1d8,0032f1c8) ret=0036ae3a
000d:Ret  advapi32.RegQueryValueExW() retval=00000000 ret=0036ae3a 
--- snip ---

The gathered info is written into an ini-style output file
"Plugins/PrereqConfigOne.log":

--- snip ---
[CheckForCPU]
Status=Pass
Message=User's machine processor speed is:2400 ~MHz
--- snip ---

The second task "CheckForRAM" queries the info using WMI, something like this
(pseudo code):

--- snip ---
long memsize = 0L;
SelectQuery query = new SelectQuery("Win32_OperatingSystem");
ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);
foreach (ManagementObject mo in searcher.Get())
{
  memsize  = Convert.ToInt64( mo["TotalVisibleMemorySize"]);
}
if( memsize >= required_size)
 ....
--- snip ---

Due to WMI proxy/subsystem failure, a System.Management.ManagementException is
thrown from .NET CLR.
The culprit: the code executing at this scope has no local exception handler
installed.

The app usually installs exception handlers within each of the data retrieval
functions to write "failure" values (ini section with Status=Fail) if an
exception was thrown.

Because the app code never anticipates that WMI connects might fail (stupid,
this might even occur on Windows), the exception gets passed up and is finally
catched at top level.

At top scope the cause for failures is searched by loading and parsing the
"Plugins/PrereqConfigOne.log" file.
Because an ini-section for "CheckForRAM" was never written (due to bad error
handling) the app fails with "Prereq.Exceptions.KeyDoesntExistException".

In short: WMI is needed or this is a no-go.

Maybe I revisit my old WMI stuff and see if it gets further with that (there
exist a bug).

Also adding direct download link, bypassing registration crap.

It might be useful to add some "WMI"/"wbemprox" component to Wine bugzilla to
target this and future bugs.

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list