I've experienced this with V6 and now V7. When installing (Win 10-64), the installer will offer to close running applications that could interfere with the installation. Upon agreeing, it succeeds in closing applications and to restart them, except for one important item: Windows Explorer. The end result is that I need to log out/in.

claude vidal wrote:When installing (Win 10-64), the installer will offer to close running applications that could interfere with the installation. Upon agreeing, it succeeds in closing applications and to restart them, except for one important item: Windows Explorer. The end result is that I need to log out/in.

I have the same problem but I put up with it.In my case - if I let programs to be closed - I end up with a totally(!) black screen and I have no other option than to hard reset my laptop.To avoid this I never let the installer close any programs (usually it's the explorer the installer is moaning about) and reboot normally as suggested during installation.

It doesn't really bother me, but it would be nice if it could be fixed in some later releases
HaPe

If it does happen you can Ctrl+Alt+Del then Start Task Manager then do the File->New Task (run) and type in explorer.exe.

But most users don't know that so I can't even begin to imagine how many users don't and use some 4 letter words when they end up with a blank screen because they choose to not reboot.

Maybe one of these days Tracker will check if Explorer.exe is running at the end of the install and restart it if not.

That function should have been built into all installers but I'm guessing the thinking is that a program even with Explorer stopped might not fully update all it's files and cause a problem when Explorer restarts. But to me I think it's far less likely than leaving the user with a Blank screen if they choose not to restart.

I've never had it completely lock up. I'm not familiar enough with their installer but there might be a log files in your temporary folder. In mine it looks like I have some named PDF-XChange_Editor_XXXXXXX.log where XXXXXXX is the date and time

The last line in the last one written was:

[2FB0:0A3C][2017-12-04T12:30:33]i007: Exit code: 0x0, restarting: No

It would be interesting to know if it was exiting on yours or if it locks up before that.

I had no issue going from 324 to 324.1 this morning personally.
that being said I noticed it hung for about 2 minutes during the update from 323 to 324 last week, I passed that along and assumed it had been fixed as I didn't experience it today.

Ill bring it up in the next meeting. Personally I believe that an update should always simply require the machine to be restarted. There is no point in keeping it on if we have to close file explorer stopping most users from operating while its ongoing anyway.

I did the update from 324 to 324.1 and it acted like before and did NOT restart Explorer in the end. For some reason though this time I had 3 Explorer instances that needed to be closed and it couldn't close them either and I had to manually End Task on them for the installation would continue.

Hello, we want to update from V6.0.322.7 to V7.0.323.2 (Opening PDFs in Sharepoint bug is finally resolved in the current version) via SCCM silent installation and got the same error. The Uninstall routine shuts down explorer.exe and because SCCM uses Local Authority rights to perform installation tasks, it cannot restart explorer.exe which is intended behavior by Microsoft.

the error ”Application SID does not match Conductor SID” will be generated whenever the user account the service is being run under does not match the user account used to launch the setup instance. The term “Conductor” refers to the MSI setup engine. It also appears that if the setup is executed with elevated permissions (Run As Administrator), then the SID check is bypassed. This behavior is by design and is intended to prevent the malicious restarting of critical system services.

This is not a good solution because I don´t want to mess with your MSI each time I want to update PDF Exchange Pro. My latest try was using WMIC (wmic product where "vendor like '%%Tracker Software%%'" call uninstall /nointeractive) to uninstall the old Application before. This prevents explorer restarts but unfortunately it restarts the PC if a PDF is open during uninstall. I´m going to try a workaround I found on Google to prevent this: wmic product where "vendor like '%%Tracker Software%%'" call uninstall /nointeractive | wmic && shutdown /a

I think the real solution would be to make it possible to enforce the setup to uninstall PDF exchange and ask for an reboot if there was a file in use instead of terminating the process.

This problem is a big one for us because if you deploy PDF Exchange Pro to >1000 PCs silently you don´t want to fix 1000 crashed explorers and nobody is able to work.

Hi Marvin,
thanks for the detailed post. The GIU installation does prompt for a choice of restart services or not so perhaps it is possible to make that an argument for the installer. Let us discuss this here and see what we can do in this regard.

It does seem very reasonable yet I am left wondering why this has not been an issue over the years, I've not seen target PCs have Explorer shutdown and unable to be restarted reported before over the almost 10 years I've been here.

Just a quick question, you said you were moving from V6.0.322.7 to V7.0.323.2 (Opening PDFs in Sharepoint bug is finally resolved in the current version), did you know that the curruent version is actually 7.0.324.2? Was that a typo or are you using 7.0.323.2?

_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Paul you would have to check with your team but if my memory serves me correct you guys used to use a different installer packager and it didn't give the option to close explorer. I can't remember if it's when you came out with the Editor that the installation packages changed or when but the non restarting of explorer.exe has been a problem for well over a year.

And I know in our code after running the driver installer we check to make sure that explorer.exe is running and if not restart it in our code. So it doesn't effect our end users but I do see it happen every time I update my own version of the end user Editor.

I did have a talk this morning with the team and while we could add an additional check for an Explorer process at the end of the installation and try launching it however it may end up with the same result - the different UIDs from the system account and user account preventing explorer from starting.

You have a work around at the moment from what I can see, calling a machine restart after the install completes, however that is a rather heavy handed thing to have to resort to so we are going to look into this further. The man at the centre of this, with the most knowledge of the MSIs and how we create/use them is not available until next week. When he is back we will further the conversation and I will report back here what comes of this.

I appreciate your thorough reporting of this case.

_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

The GIU installation does prompt for a choice of restart services or not so perhaps it is possible to make that an argument for the installer

This could solve my problem but I tried overwriting this dialog via Orca (Default setting to prompt for restart) for another setup with this issue and it did not work. I can test this out with your setup, too but i don´t have a public property to override this without manipulating the MSI. I saw that the Property UIRMOption has two options. UseRM and DontUseRM. The order is to first use "UseRM" (&Close the applications and attempt to restart them.) and then "DontUseRM" (&Do not close applications. A reboot will be required.) Maybe adding a public MSI Property to manipulate the order or let me choose between these two would solve this as an workaround. There is also a property UIRMOption with the Value UseRM. Unfortunately these properties are the same if I take a look at the MSI V5.5.316.1. I can´t remember to have this error before V6 so the root cause must be somewhere else.

Thank you for your post. Upon some further investigation, we have ascertained that this is caused by a windows update bug which we found to be fixed in Microsoft's Insider's release. Because this windows update may take some time to make its way to the general public our dev team has decided to incorporate a workaround with the next build of our software.

Thank you for your patience and understanding.
Cheers!

If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

So again I locked myself out installing V7 324.3 and specifying auto close apps.

Patrick-Tracker Supp wrote:16 Feb 2018 20:23... Upon some further investigation, we have ascertained that this is caused by a windows update bug which we found to be fixed in Microsoft's Insider's release. Because this windows update may take some time to make its way to the general public our dev team has decided to incorporate a workaround with the next build of our software.

Hello Claude,
I moved you new topic into this one as these was no reason to have a separate topic for the same discussion.
I am sorry to say we are still looking on ways to fix this, and Microsoft still has not released a fix from their end, it will likely be months before they do anything about it.

Hi Schottel,
We have made some changes, and it should be fixed, I'm my test just a minute ago it all worked fine, I wasn't even prompted for a restart while updating, so I think it would be safe to say you should find the same situation.

This should now only prompt you if you have windows open that need to be closed for the installation to complete. Once those are closed, (or if they are closed to begin with) it should be nice and smooth.

Did not work in my case (325.0 to 325.1). Asked to close Outlook and Explorer. Succeeded in closing Outlook, then came back with 'Couldn't close all apps...". Hit OK, then saw Explorer disappear and waited another 20 seconds. Another 'Couldn't close all apps...", hit OK, then installation appears to continue and finish. Outlooks comes back, but no Explorer.

Hmmm. thank you for the report there...
I will bring it back to the dev team. I believe they had hoped this would work as an interim fix until Microsoft releases the next update for windows.
The issue was initially caused by a windows 10 update (windows is supposed to restart explorer automatically), and that has been resolved in their insider preview, meaning that (hopefully sooner than later) this will be fixed by that update. In the meantime we have been trying to find workarounds that wont conflict with windows itself once that update rolls out.

Most of our team are on the official release channel. It is only some of our devs that are on the Insider Previews so I do not have the exact build that is fixed in - but it should be out to the general public soon as well!