We are running .Net 2.0 primarily but we have run this in environments with many other variations.
The problematic environment has always been the 2008 64bit R2 which usually has everything up to 3.5 intalled.

Be sure it's R2 specifically. We had many clients reproduce the error. Thus, the need for our change. It definitely had something to do with the /clr switch. Even if we made NO CALL, that switch seemed to make all the difference. I'm not sure we can send the actual dll and installer program... but, ...

Yes, we were still seeing this behavior on the 2008 R2 64bit platform specifically. As a matter of fact, it became such a big issue, that we re-wrote the dll. We think the core of the issue is related to the fact that the dll simply had the /clr switch. We were using the .NET framework but, just hav...

I just tried setting the 64bit modes explicitly using the Set 64bit Mode command. The little sample installer we provided above continues to hang on a 64bit OS but works fine on 32bit even with these commands in place. Can anyone else verify this behavior? I saw a slightly similar post: http://www.i...

bump? This continues to be an issue for us. I'm surprised others haven't seen the same issue yet. Again, we packaged up a small, repeatable installation and custom dll to illustrate the problem. Unfortuately, we are going to have to resort to a work around, passing values between a text file, if the...

I am seeing the same thing. It's almost as if the unpacking process isn't protected by this check. Both instances go through the unpacking and then the second instance fails with the access violation. Any progress on this? I'd be happy to send my setup scripts (it's rather large) to support if you'd...

~InstallAware Clipboard Data~ ~Run Program As~ ~{BE0B1D1D-383B-4EAD-A52F-B9D7DC3258DA}~ ~REG~ ~~ ~IMPORT $SUPPORTDIR$\\ReceiveTimeout.reg~ ~1~ ~~ ~~ ~~ ~~ ~TRUE~ ~~ I added this at the end of our installers. This appears to have worked well on 32 bit boxes. We are testing this on 64bit bo...

A few possibilities ... 1. Do your clients have run any other install program that could have used IA? 2. Could IA be changing other registry settings that we have not identified yet (perhaps ones that might affect servers)? 1) Good point, although I haven't run OUR setup on my Dev box, I do have t...

Interestingly enough, IA only installs our website and supporting services. We definitely see the timeout when running a client on the IIS server itself. However, we still see the timeout on any IE client connecting to the server. This is why we were thinking it was a Microsoft updates introduced pr...

I'd just like to add a quick reply to this post as well. I've been battling this for the last 4 or so months as well. We had tracked it down to the same registry keys listed here but we were thinking that Microsoft had released a patch or something that was auto updated. I was at a loss as to why, a...

This is the IA App... I couldn't attach these files with the original post.

File Attached:

IADllTest.zip

I couldn't attach these in the original post

File Attached:

DLLIssue.zip

We have identified a repeatable situation in which the first call to our dll succeeds and the second call hangs. The dlls calls work just fine on a 32bit OS but exhibit this behavior on a 64bit OS. We have created a small repeatable application to illustrate the problem. The app is commented to expl...

We have spent a great deal of time troubleshooting connectivity issues with a just a few clients. We ended up using a network sniffer to determine that the MS SQL Server plug-in is connecting via SMB port 445 as opposed to port 1433. We found that these clients have disabled the SMB port 445 for fil...

My setup test was a success. No compile or build errors and the install was smooth.

Once again, thanks for taking care of this.