InstallAware

Hi,

I found that InstallAware 9 modifies (alongside with other registry keys) the HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout key and sets the value to 10 seconds. This setting is done prior the actual installation procedure, but what is worse this change is persistent.


I found out that the following keys are modified without any specific command in the MSIScript to do so:

HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\MigrateProxy
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\ProxyEnable
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\AutoConfigURL
HKCC\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\ProxyEnable
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\Connections\\SavedLegacySettings
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\ProxyBypass
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\IntranetName
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\UNCAsIntranet
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\ProxyBypass
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\IntranetName
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\UNCAsIntranet
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\Connections\\DefaultConnectionSettings


I believe this is quite a serious bug, because it has many possible side-effects on another applications, which persist even after you uninstall the product completely (I have an example of a client who lost ability to work with his intranet web applications because of these changes, we had to do a system restore to get it back working, simple uninstallation did not help). So this is definitely something which I believe should be addressed in next IA version.

For the time being, is there a way to stop this happening, i.e. either to stop IA from modifying these values or at least to force IA to restore these keys to their original state once the install is done (no matter if the install succeeded or not)?

Best Regards,
Lukas Neumann

lneumann wrote:Hi,

I found that InstallAware 9 modifies (alongside with other registry keys) the HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout key and sets the value to 10 seconds. This setting is done prior the actual installation procedure, but what is worse this change is persistent.

I found out that the following keys are modified without any specific command in the MSIScript to do so:

HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout
HKCU\\Software\\Microsoft\\windows\\CurrentVersion\\Internet Settings\\MigrateProxy
...

What specific version of IA are you on? 9.0.6?
Did you regenerate your license to ensure that you're using the latest runtime engine?
What version of Windows did this happen on? What was the version of Microsoft Internet Explorer?

Thanks,
Troy

lneumann wrote:Hi,

I found that InstallAware 9 modifies (alongside with other registry keys) the HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ReceiveTimeout key and sets the value to 10 seconds. This setting is done prior the actual installation procedure, but what is worse this change is persistent.

Yes, this is an EXTREMELY CRITICAL BUG in IA 9. Some (not sure what type) installers created by IA 9 apparently causes this problem. I also found out that once a week, a program called myahe_sw.exe is called that also whacks that registry setting (I had to run a registry spy to find this). I assume that this is some weekly licensing/activity call-back to IA.

I was told by IA support to modify MY install program (!!??!!) to save/delete this registry setting (of course this does not help with the weekly license check myahe_sw.exe)

Let me explain how serious this issue is ... this registry setting affects all IE browsing ... it basically tells it to fail any page request that takes 10 seconds. This means things like searches on online forums (I had a page error twice today on this forum searching and posting because of this bug) will sometimes fail, it means that web applications will sometimes fail, it means that some pages for some sites will not load completely/correctly (random javascript errors, and page-layout errors). On EVERY website. And every app that uses the IE engine (like Outlook).

This has been an absolute nightmare support-wise for our company. Until we realized that some IA setup programs (and IA itself) were causing this, we got Microsoft involved because the results were so crazy (our customers of course held us responsible). I am also concerned what other registry settings may be wacked as well. These settings should NEVER be changed by something like a simple install program. NEVER! We actually had to send out a newsletter to our customers to watch for IA created install programs so that they could reset this setting (we sell a web-based application that was crippled by this bug).

I am hoping IA will acknowledge this as a bug and have this patched (I brought it to their attention on July 12). I guess the first step is to have them agree that this is indeed a bug.

We acknowledge that this issue exists, and that we are going to resolve it in a Service Pack edition.

I apologise for the issues that this causes, and I can assure that we will be releasing a fix.

As for the myah_sw.exe; I'm not actually sure what this is, but it could be a callback for checking for updates -- we do not employ any callback mechanisms for activity or licensing purposes.

That is good news (about an upcoming fix). The myahe_sw.exe program is in the C:\\Documents and Settings\\All Users\\Application Data\\{9241F66D-CD91-449D-8EF7-FE9921F95BA4} folder ... searching thru the registry it is the InstallAware for Windows Application itself (it actually contains all the runtimes for MS SQL, Crystal, dot NET, etc).

Is there any way to disable this weekly http check?

Andy, any ETA on the service pack you mentioned earlier?

This isn't a bug at all. The default timeout is one hour. This means that if a server times out during any kind of download (could be a Download File command or a Web Media Block declaration), your installer will freeze for an hour before the IE download engine reports at time-out. This is in fact a fix to the IE download engine's one hour long default time-out, which is extremely unreasonable by any standard.

You can override this in your installer as described earlier. The installer writes to a single key, it does not write to the plethora of keys shown here. Other software or engines might be propagating this change to other keys, but its not InstallAware.

The weekly check is the task you scheduled yourself for InstallAware updates. You yourself picked that schedule. Nothing funny is going on, this is not licensing related, it is an innocent check for updates that I once again repeat was scheduled by you yourself.

As for this setting affecting other programs, in our testing, no other software is affected by this change. We also use Outlook and other software that use the IE download engine at InstallAware. There might be other third party software causing these problems.

We will provide an option to disable writing this key in future builds (most probably via a compiler variable), but I just wanted to clarify some confusion here. With InstallAware 9 or higher, even with an hour long timeout, canceling the installer will quit immediately, so it is relatively safe to disable this feature, even if it would be very inconvenient to do so (with a short timeout, the installer will re-connect and resume the download upon an interruption).

MichaelNesmith wrote:This isn't a bug at all. The default timeout is one hour. This means that if a server times out during any kind of download ... your installer will freeze for an hour before the IE download engine reports at time-out. ... You can override this in your installer as described earlier. The installer writes to a single key...

I agree that an hour is too long. But I've found 10 seconds too short as it's caused other (slow) websites to stop working ... only for me to figure out that this registry key has been mysteriously modified.

Perhaps you could change the timeout within the session used by the application so that you don't have to change the registry key. Here's how I do it within my application:

InternetSetOption(hConnect, INTERNET_OPTION_RECEIVE_TIMEOUT, @dwFlags, sizeof(dwFlags))

--Troy

Hi Troy,

R&D did try that function, however it was not reliable. In testing, on most platforms, the call was ignored, with no effect on the time-out value.

Unfortunately, the only absolutely reliable method was setting the registry key. We did this research and we decided on this as being the best implementation.

Probably my recommendation to R&D will be having a compiler variable that specifies the exact time-out value in seconds, with 0 being "do not change".

MichaelNesmith wrote:R&D did try that function, however it was not reliable. In testing, on most platforms, the call was ignored, with no effect on the time-out value.

Thanks for letting me know this. I wasn't aware. It'll affect my own apps.

MichaelNesmith wrote:Probably my recommendation to R&D will be having a compiler variable that specifies the exact time-out value in seconds, with 0 being "do not change".

This would certainly satisfy me.

Thanks,
Troy

MichaelNesmith wrote:This isn't a bug at all. The default timeout is one hour. ... This is in fact a fix to the IE download engine's one hour long default time-out, which is extremely unreasonable by any standard.

I understand the development challenge you faced using the IE download engine, but our customers (and myself) would not consider what was done to be a "fix" to IE. This is a GLOBAL system change ... not just for the install program. This affects every user using the IE browser. Not just downloads ... but simple page navigation!

MichaelNesmith wrote:As for this setting affecting other programs, in our testing, no other software is affected by this change. There might be other third party software causing these problems.

IA changing this single registry setting has a very real and absolute affect on all users of IE. It is not other software ... it is this single registry setting being changed that causes problems -- reverting back to the original setting removes the problem. I am not sure I am being clear on the affect of globally setting this value to 10 seconds ... it means that all browser requests that take 10 seconds will be cancelled (web pages, javascript, CSS requests, etc). So when users navigate forums (for example) using the browser and hit search, which sometimes take 10 seconds, the page request is timed out. In fact, just searching THESE forums after having this registry modified sometimes results in page errors. Also, many people browse via a VPN or a proxy which add delays to web applications (Salesforce.com, SAP, etc) and web sites ... before we knew that this setting was changed, we recieved numerous complaints from our customers that their browsers were getting time out errors (of course they blamed us). The reailty is that this setting was set that way by MS for a reason. Changing it globally to such a low value IS causing problems. Is there no way for you to change to value temporarily ... or use asyncronous calls instead (the best approach)?

MichaelNesmith wrote:The weekly check is the task you scheduled yourself for InstallAware updates

Is there a way to modify this setting or view the current schedule?

I'm a bit confused about precisely when InstallAware adjusts (or creates) the IE ReceiveTimeout registry entry.

I distribute my software with InstallAware, and I've never seen this registry entry get set. In fact, I just ran a test and used RegMon to capture all registry changes during the installation of one of my products. I could find no references to ReceiveTimeout in the results.

I also scoured the registry of the test machine in question, and still didn't find any references to a ReceiveTimeout value.

I'm running the latest release of InstallAware on Windows 7 (64 bit).

What am I missing??

MarkRichards wrote:I'm a bit confused about precisely when InstallAware adjusts (or creates) the IE ReceiveTimeout registry entry.

I distribute my software with InstallAware, and I've never seen this registry entry get set.

Same thoughts here. I've experienced it with my own machine's registry being set (I think after installing InstallAware, but I'm not 100% sure). But I can't reproduce it with my own installer. Perhaps it happens right before a Web Media block is downloaded? (haven't tested that scenario)

--Troy

It'll be set when a Web Media Block or Download File statement executes. The former won't "execute" unless you're building in web mode, and you've executed a function like Install Files after entering a Web Media Block declaration.

MichaelNesmith wrote:Hi Troy,

Unfortunately, the only absolutely reliable method was setting the registry key. We did this research and we decided on this as being the best implementation.

Probably my recommendation to R&D will be having a compiler variable that specifies the exact time-out value in seconds, with 0 being "do not change".

Settings a compiler variable might sound like a good idea, but it doesn't help anyone on the Developer or Express editions that can't use them.

I don't see any problem in setting the registry key... as long as it's changed back after the install is completed. Surely if the IA Engine can set the value, then it could set it back again to the prior value afterwards. Or is there something I'm missing in regards to the logic of that?
Cheers.