Interacive Service Detection at Silent Installation

[Ticer]

Hi all.

When installing pdf xchange pro v4 with silent command as local system on window s7 64bit, the logged on user gets an Interactive Service Detection. It happens somewhere at the end of the installation, after the shortcuts have been created on the desktop.

the install command is:

Code: Select all

/VERYSILENT /NORESTART "/Key:xxxxxxxxxxxxx" "/UserName:xxxxx" "/Organization:xxxxx" /Lang=gr /L /LOG="C:\xxxxxx\xxxxxx.log"

and the event log entry is:

Code: Select all

A device or program has requested attention. Device or application: C:\Windows\system32\SHELL32.dll. Message title: Persönliche Einstellungen.

Persönliche Einstellungen means something like personal settings.

i didnt had this problem before with version .212 or .213. it suddenly happend with those versions lately, also with the latest .214.
First i thought it would have to do with the latest windows updates, but then i tried to install the program on a fresh windows 7 64bit without updates and it happened too.

anyone know what could be wrong?

[Stefan - PDF-XChange]

Hello Ticer,

We've just tried running this command line:
pdfx4.exe /VERYSILENT /NORESTART /Key:"xxxxxxxxxxxxx" /UserName:"xxxxx" /Organization:"xxxxx" /Lang=gr /L /LOG="C:\tmp\pdfx4.log"
And it didn't cause us any problems.

Could it be that the folder in which you are trying to store the log file is causing the problem?

Regards,
Stefan

[Ticer]

hi.
i dont think that the log folder is the problem. i'm using the same log folder for all other silent program installations too. and so far pdf xchange pro is the only program that caused the problem lately.

[Stefan - PDF-XChange]

Hello Ticer,

We did run some more tests, but still can't reproduce the problem. In fact the installer for V4 itself has not been changed since 8 Aug 2013 - just the files inside that it is deploying, so it is the same installer as in previous builds.

Regards,
Stefan

[willyg]

Hello.

I see similar behavior in version 10.5.2.395 after installing (or uninstalling) MSI via GPO on Windows 7.
The reason is explorer.exe starts in session 0 by msiexec.exe during installation process.
Then its activity is detected by Interactive Services Detection service.

Maybe, problem is installer trying to do RestartShell action despite no shell exist for SYSTEM user.

[Paul - PDF-XChange]

Hi, willyg

can you use /FORCERESTART and let me know if it works?

It is often the case that trying to close applications that have a handle on files that need to be replaced can have undesirable outcomes.

Given that this is on Windows 7 that is officially no longer supported I would be keen to hear if switching to a flag files for replacement on system restart paradigm helps.

[willyg]

Hi.

Thank you for quick response.

I'm using package assigned to computer method, so there is no logged-in users or applications running during this boot-time deployment process.

But the only way regular user (logged in later) can get rid of the annoying recurring warning from Interactive Service Detection service (UI0Detect) is, indeed, restart the PC.
It works because PDFXCE is already installed, so installation process does not invoked again (and no explorer.exe will be started by it).

If you still want me to check /FORCERESTART option, please tell what exactly needs to be added to my MST (MSI transform) file.
Thank you!

[Paul - PDF-XChange]

Hi, willyg

it is an MSIEXEC.EXE argument. This worked for me:

Code: Select all

msiexec.exe -i EditorV10.x64.msi transforms="yourtransform.mst" /FORCERESTART /qn

I am keen to hear if that helps.

[willyg]

Hi.

As I mentioned, msiexec is invoked by the group policy, so there's nowhere I can put /forcerestart parameter except, maybe, MST file.

If I run your command line manually, PC restarts immediately after installation.
No warning from UI0Detect, obviously.
Overall, I'm not sure, what was this test for.

If I'm allowed to repeat myself: problem is installer starts explorer.exe under non-interactive session 0 of SYSTEM user (during RestartShell action).
This should never happen.
It is installer logic flaw as explorer.exe should be restarted only if it was running before and never under SYSTEM account.

Here is excerpt from the install log:

Code: Select all

Action ended 13:28:35: InstallFinalize. Return value 1.
Action start 13:28:35: CA_RestartShell.
RestartShell:  Num processes: 52
RestartShell:  Process 'explorer.exe' found: 0
RestartShell:  SE: 42
Action ended 13:28:35: CA_RestartShell. Return value 1.
Action ended 13:28:35: INSTALL. Return value 1.

[Paul - PDF-XChange]

Hi, willyg

the request was twofold:
1. to see if /FORCERESTART changes the behaviour from trying to restart explorer
2. to trigger an install log. - you should se eon in %tmp% - something akin to \MSIxxx.log

I cannot speak to the accuracy of the assumption that "It is installer logic flaw", it may be an MSIEXEC.EXE issue beyond what we can control in the package. If you send us the full log by email to support@pdf-xchange.com, with a reference to this thread I can pass it on to the development team for analysis.

[willyg]

Hello.

If you send us the full log by email to support@pdf-xchange.com, with a reference to this thread I can pass it on to the development team for analysis.

Done.
Sorry for the delay.

[Stefan - PDF-XChange]

Hello willyg,

Thanks for this! I can confirm we've received the file and Paul will check that with our devs soon!

Kind regards,
Stefan

[Paul - PDF-XChange]

Hi Willyg

the devs will investigate. We have raised a ticket to track the progress of the investigation. While for internal use only, should you refer to RT#7349: /FORCERESTART does not prevent Explorer.exe being closed here, then any support staff member will be able to get you a status report.