6 replies to this topic

[deramor]

Hello-

 

I have a basic msi project which appends to the PATH environment variable on Win7.  After installing my software, the system becomes unusable.  For example, I lose many icons for my shortcuts.  I can't execute anything from a RUN dialog that exists in c:\windows.  The behavior has been previously diagnosed by us as a corrupt PATH variable (or at least a variable that is now unknown to the running processes).

 

Usually a log off or reboot fixes this behavior.  In 10% of the cases, this is not fixed and there is no recovery short of restoring the PATH variable from a backup.

 

This only happens on systems when installs are run that modify an already very long PATH variable.  I talked to my software architect and she mentioned that all it would take is some helper dll to have a small limit in it to get in this state.  My question is, does anyone know how the Environment Table writes changes to a variable? 

 

Is there a manual way to write an environment variable?  Would it be acceptable to write the PATH variable in Installscript?

[Glytzhkof]

Just for the record: I think far too many applications make heavy use of the PATH variable, it is safer to use internal defaults in the application, registry keys or other ways to set the full path to executables. Please read this: http://msdn.microsof...1(v=vs.85).aspx. This shields you a bit more from other applications and installation packages and whatever they might do wrong.

 

With regards to the length restriction, perhaps this helps: http://blogs.msdn.co...03/9957320.aspx

Edited by Glytzhkof, 09 January 2015 - 07:36.

[deramor]

In this instance, the "application" is a driver which customers write programs against our API.  The dlls they link against need to be in the PATH in order to be found at runtime. 

 

I suspected there was a limit in the method used to process the variable changes.  Does anyone know what the limit is of the Environment Table in Windows Installer? 

[Glytzhkof]

Beyond limits the PATH variable can be wiped out by bad coding in any application package being installed on the system. I have seen this many times and it is one of the biggest corporate headaches ever (it causes a completely broken system for developers especially).

 

I was planning to add standardized code in a packaging dll to inspect the PATH variable for unusual changes and trigger rollback in an SOE environment - I never got around to implementing it, we beefed up QA instead. You might want to consider this as an option for your setup and a way to gather more data as to what is really going on on the problem systems.

 

I haven't done driver installs in ages, and I am not sure what the latest, updated convention is from Microsoft, but I would just put the dlls in System32/64 so that they are implicitly available to the system from any other tool. What do you think Stefan?

[Stefan Krueger]

As far as I know, there's no document detailing the inner workings of Windows Installer when it creates or modifies environment variables.

I don't think that doing the modification yourself would solve the problem, but as Stein suggested you could write code to check the length of the existing enrty and detect before it's getting too long. However the consequence would be that your software simply can't be installled unless the user manually shortens the existing PATH. I don't know if this justifies putting it in a system folder.

 

But lets take one step back. Can you replicate the problem? Are you really sure it's the length of the PATH? Did you look at the PATH before and after your setup runs? Is it truncated or damaged in some other way? Do you append your own path at the end of at the beginning of the PATH?

And on which Windows versions does this happen? There might be differences in versions and bitness.

[deramor]

Answers to your questions:

The problem is environment specific.  The PATH must already be long enough to get into the funny state.

When the path gets really long, I notice that none of the Windows components can be found.  The System32 folder can't be found which effectively breaks Windows.

I look at the PATH after my install and it is not damaged.  The data is appended and correctly separated with semi-colons.  I've been able to copy the data before and compare it after to confirm.

This is on Win7 though I have not tried it on XP or 8.

 

In some cases, it is sufficient to log out and log back in.  Things start working again.  So maybe I'm not correctly sensing the broadcast message to all apps?

 

In other situations that are really bad, a log off or reboot will not fix it.  I do not know why this occurs as I have only heard about this scenario from my sw architect.  I have only personally observed that a log off and log in will fix it.

[Stefan Krueger]

So if the PATH isn't corrupted, Windows Installer itself seems to work properly. Instead, Windows or some applications can't use a PATH that's too long. Here are two links that discuss the maximum length of environment strings:

http://blogs.msdn.co...03/9957320.aspx

https://msdn.microso...3(v=vs.85).aspx