Archive for September, 2007|Monthly archive page
In my previous post, I mentioned a reboot seemed to fix my network connection error when I tried to update. However, the problem was actually that the path length to Eclipse was too long. The folder I copied Eclipse to was this, which resulted in broken updates:
C:\Program Files (x86)\Eclipse-3.3-wpf
However, Eclipse Updates started working when I changed to folder name it to this:
C:\Program Files (x86)\E-3.3-wpf
I am trying to use Eclipse 3.3 (Europa) from Vista x64. Everything seems to work fine except for the Preferences dialog. The General/Key tab is missing most of the GUI the first time I view it and is blank every other time. This means that I couldn’t change any of my keybindings (key bindings).
I tried a million different things to get this to work. Finally I tried a using a beta 3.3-wpf release of eclipse, which does render the preferences correctly! Come to find out so does 3.4-wpf. However, 3.4 without wpf does not render correctly. So, something with the win32 graphics library is broken. Eclipse 3.2 didn’t have any problems, so it’s something that was introduced with version 3.3.
However, when I tried to do an update from the newer versions, I got weird connection errors:
Network connection problems encountered during search.
Unable to access “http://sitename“
Error parsing site stream. [Premature end of file.]
Premature end of file.
But from my original 3.3 version, updates worked find. In this case, a reboot seemed to have fixed something, but I don’t know why.
This was actually a very simple error to fix once I knew the cause, but the problem is that the Microsoft knowledgebase didn’t give the correct answer and there are no log files to be found to help find the correct cause, things were severly complicated by the fact that every search result I could find on the error insisted that it was a security problem. Finally, I had to just guess, and I was right. 🙂
The problem turned out to be that I installed another app that switched IIS to use 32-bit mode. All I had to do was switch it back to 64-bit (x64) mode and SharePoint worked again.
First, fix IIS:
\inetpub\AdminScripts\cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 False
Second, reregister the .Net isapi filters:
That’s it! How about some better logging, Microsoft?