Diagnostics.Process & MSIEXEC problem...

[Rob R. Ainscough]

I'm using the Diagnostics.Process approach to shelling out run the
following:

C:\Windows\System32\MSIEXEC.EXE /x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q

..FileName = "C:\Windows\System32\MSIEXEC.EXE"
..Arguments = "/x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q"
..Start()

I do a WaitForExit and get an error code back from MSIEXEC of 1605 -- this
means product not installed. So I go into the registry to locate the
produce code and verify that it does indeed exist. Since I'm baffled as to
why shell ot MSIEXEC would return this error when the product IS installed,
I decide to try Start | Run and enter the exact same:

C:\Windows\System32\MSIEXEC.EXE /x {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B} /q

and it works!!? So now, I'm really baffled.

So why is does this NOT work using Diagnostics.Process approach? Obviously
the product does indeed exists.

Rob.

P.S. - this is basically uninstalling a product (

 

[Cor Ligthert [MVP]]

Rob,

As this is your total code than it is definitly wrong because you are not
adding the ProsesStartInfo to the proces..

See this sample to open regedit.

\\\Registry
Dim p As New Process
Dim pi As ProcessStartInfo = New ProcessStartInfo
pi.FileName = "regedit"
pi.Arguments = "/S C:\yourRegFile.reg"
p.StartInfo = pi
p.Start()
///

I hope this helps,

Cor

 

[Rob R. Ainscough]

Cor,

I didn't post all my code, just the critical parts. The start process is
working fine as MSIEXEC is returning 1605 error code. I'm going to try to
log the MSIEXEC output but according to Microsoft 1605 means "This action is
only valid for products that are currently installed."

What has me really puzzled is the exact same command entered via Start | Run
works fine. There must be some undocumented "feature" of the Process or
something? I've talked to other developers that have received the 1605 from
MSIEXEC when it had nothing to do with the actual error.

Thanks, Rob

 

[Rob R. Ainscough]

This is what the MSIEXEC logging produced:

=== Verbose logging started: 7/20/2006 14:39:46 Build type: SHIP UNICODE
3.01.4000.2435 Calling process: C:\WINDOWS\system32\MSIEXEC.EXE ===
MSI (c) (A8:80) [14:39:46:625]: Resetting cached policy values
MSI (c) (A8:80) [14:39:46:625]: Machine policy value 'Debug' is 0
MSI (c) (A8:80) [14:39:46:625]: ******* RunEngine:
******* Product: {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B}
******* Action:
******* CommandLine: **********
MSI (c) (A8:80) [14:39:46:625]: Client-side and UI is none or basic: Running
entire install on the server.
MSI (c) (A8:80) [14:39:46:640]: Grabbed execution mutex.
MSI (c) (A8:80) [14:39:46:671]: Cloaking enabled.
MSI (c) (A8:80) [14:39:46:671]: Attempting to enable all disabled priveleges
before calling Install on Server
MSI (c) (A8:80) [14:39:46:687]: Incrementing counter to disable shutdown.
Counter after increment: 0
MSI (s) (30:90) [14:39:46:734]: Grabbed execution mutex.
MSI (s) (30:64) [14:39:46:734]: Resetting cached policy values
MSI (s) (30:64) [14:39:46:734]: Machine policy value 'Debug' is 0
MSI (s) (30:64) [14:39:46:734]: ******* RunEngine:
******* Product: {73F1BDB7-11E1-11D5-9DC6-00C04F2FC33B}
******* Action:
******* CommandLine: **********
MSI (s) (30:64) [14:39:46:734]: Machine policy value 'DisableUserInstalls'
is 0
MSI (s) (30:64) [14:39:46:750]: MainEngineThread is returning 1605
MSI (c) (A8:80) [14:39:46:765]: Decrementing counter to disable shutdown. If
counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (A8:80) [14:39:46:765]: MainEngineThread is returning 1605
=== Verbose logging stopped: 7/20/2006 14:39:46 ===

Not helpful at all.

Rob.

 

[Rob R. Ainscough]

Ok, the plot thicken's

Addendum:

The root of the problem seems to steam my Windows Service (interacts with
desktop is checked) shell. Here is the sequence:

DUSM.EXE (my Windows Service running un LocalSystem with "interact with
desktop" enabled)
DUSM performs a Process.Start which loads DUSM_UI.EXE
DUSM_UI.EXE performs a Process.Start which runs the MSIEXEC (see below)
Results: 1605 error (this appears to be a bogus error reported by MSIEXEC
but product does NOT uninstall)

Since DUSM_UI.EXE is a stand alone program I can run it directly (double
click in Explorer)
run DUSM_UI.EXE (from explorer) which performs a Process.Start which runs
MSIEXEC
Results: 0 (no errors and MSIEXEC performs the uninstall)

So this looks like some type of thread restriction being imposed on MSIEXEC
when its source thread path originates from a Windows Service.

The $64,000 question -- how can I work around this problem? My DUSM service
MUST be the originator of these tasks, what are my options? Where do I even
start to look for answers?

Rob.

 

[Cor Ligthert [MVP]]

Rob,

Did you try it already as a simple winform program. AFAIK can a
windowservice in Net not standard connect to the UI (what the shell in fact
is)

Cor