I had a similar problem, where my apps were working fine until people started trying to access them using IE9. I assumed at first it was IE9, but then realized the problem was actually occurring for users on 64-bit workstations; 32-bit workstations worked with no problems.
So I just read your solutions, and found that copying a wwipstuff.dll into each application's BIN folder seems to have solved the problem. I don't know why or how using different browsers affected the web server's ability to locate the file, but, hey, it worked!
Just thought you might find this interesting....
Thanks,
Kirk Allen
Sure, I understand what you're saying. But this whole thing and the fixes has really been an odd one. How do these changes on the client affect behavior on the server? This most recent time, I did goof up and dropped the file during the transfer, but in the previous cases the file was there. What I haven't seen explained is how changes to the client affected the server. Why would one computer get the error, but not others? Why could one user ID get the error, but another user ID on the same computer not get the error? Why did they get it in IE, but not Firefox?
Security might affect you in some other way but the DLL not found error means just that - the DLL isn't there. if there's a security error (file permissions) you would get a different error I think (access denied).
IE security can cause OTHER problems for sure. If IE or the firewall are locked down you may not be able to access the internet from your application, but that's a whole different set of problems.
Security needs to be addressed by those people that impose it :-) Otherwise there's no knowing what to check for.
+++ Rick ---
The first time I ran into the problem, I was at a loss about what was causing it. Others were hitting the web site without any problems. The person experiencing the issue consulted one of their IT guys who - for whatever reason - reset the security settings to default and the problem disappeared. Now, did he do something else, too? Perhaps, but that's all he told me and the problem went away without any changes by me.
The second time was similar. One person getting the error, no one else getting it. Security settings were already at default. IT guy noticed that the IT ID on the machine could hit the site with no errors, the user's ID couldn't. Recreated user profile, problem solved.
Third time, the security settings change did not work. User did not want to recreate profile (can be a hassle, can lose data). Installed IE 9, error went away.
None of these fixes included any changes on the server.
This most recent time, I got tripped up because - indeed - the DLL was missing. Oops. But in the other cases it was there, I checked.
So you're doubtful on the security settings fix . . . ok, maybe the guy also made some other change, but why is the fix always on the client side, without changes on the server side (except for this recent one when the file got lost in the server changeover)?
As before while I can appreciate your pain, if the DLL is not there it's just not going to work :-)
The IE security have no bearing on the DLL not accessible error. In fact, wwHttp doesn't use wwipstuff.dll for the actual send/receive requests - it only uses it for some of the URL Encoding/Decoding and then only if the buffers are greater than a certain size.
+++ Rick ---
Yeah, I had already checked that this morning and, indeed, the DLL had gotten lost when we moved to the new server, but since I was able to hit the site and others were able to hit the site, I figured it was the same problem of the past (same error, for sure). And I was proceeding with what fixed it in the past. But I came to my senses this morning and checked for the DLL existence and it had not been moved to the new server. It was in the WCONNECT folder, however, so it seems that sometimes it was locating it and sometimes not. Putting it in the app folder seems to have solved this issue.
HOWEVER . . . in the past it was always available in the folder and that *was not* the issue. In those cases, the fix was accomplished via one of these three methods:
1) Reset the security settings under Internet Options - Security tab to the default.
2) Install Internet Explorer 9.
3) Delete the users profile and recreate a new one.
In the previous cases, I never made any changes to the server. One of the above options fixed the problem.
Could it be some sort of anti-virus software that's deleting the DLL? Can you check on those machines it fails on that wwipstuff.dll IS ACTUALLY THERE? I have a feeling for some reason the file is getting deleted and that would account for the failure.
+++ Rick ---
This thing is haunting me! One of my client's users is getting this now and she claims "It’s not just on my computer. It’s on other computers here at the office as well." In the past, it's been on just one computer. In fact, for one of the most recent occurrences the user got the error, but when the IT guy came in and logged in on that same machine using the user ID for IT, which they installed on all their computers, he could hit the site just fine (and they could hit it from other computers in the office). So he deleted and recreated the profile for that user and that fixed the problem. The user running into this problem today has not tried that, yet, because she thought I was talking about something on the website and she can't log in, so she thought - I imagine - that was a dumb suggestion she couldn't follow through on.
Here is her error:
This request cannot be served at the moment due to technical difficulties.
Error Number: 1753
Error: Cannot load 32-bit DLL WWIPSTUFF.
Running Method: urldecode
Current Code:
Current Code Line: 2104
Exception Handled by: Weblociprocess.Error()
As I've pointed out previously in this thread, other users are accessing the site with no problem at all. Still can't figure out why one person would get the error while others don't. It does not happen when she uses Firefox, but there are other issues with Firefox because there's a good deal of JavaScript and it's only now that it's being converted to JQuery to address cross-platform issues. That's mostly done and should be installed in a few days. However, I'd say that more proof that it's not a server issue.
This woman uses the site more than anyone, so she's found things we've missed in testing and now this happens. I imagine she's frustrated at this point. So am I. I'd like to find the root cause. Tell me this is not a bizarre issue?
I'm not sure what would cause the DLL not to load other than it's not physically there or in the FoxPro path. That includes security permissions that may not allow read access to files in a folder where the DLL lives or no access to some of the basic system dependencies like WinInet/c runtimes etc.
Maybe somebody removed wwIPStuff.dll?
+++ Rick ---
