"Security", "Sharing" and "Quotas" tabs missing in Windows XP

Today I came across a machine that had no "Security", no "Sharing" and no "Quotas" tab inside the Explorer for folders or drives (especially for the C: drive this is annoying).

Searching on the web for a solution just brought up the usual "You need to disable Simple folder sharing inside Folder options" that did not help at all.

Several hours of searching in very obscure forum systems and stumbling across ShellExView (http://www.nirsoft.net/utils/shexview.html) finally revealed the solution: Several system DLLs were not correctly registered inside the registry and thus the tabs were missing.

Using ProcessMonitor I was able to identify the dlls that were missing and created the following batch file:

REM Security tab
regsvr32 rshx32.dll

REM Quota tab
regsvr32 dskquoui.dll

REM Offline Files
regsvr32 cscui.dll

REM Previous Versions
regsvr32 twext.dll

REM Remote Storage
regsvr32 rsshell.dll

REM Distributed File System
regsvr32 dfsshlex.dll

Please note: This simply includes all extensions (Context Menu Handler and Property Sheets) I was able to identify. Some of them might not exist on your system and thus you might get a "File not found" error.

Once this script has run inside a command shell the tabs magically appeared again.

Windows SharePoint Services 3.0 : Unexpected error

Today our Windows SharePoint Services 3.0 (WSS3) issued a typical Microsoft error message: "Unexpected error". That's all: it displayed no other message is and no information in the event log of the server. BIIIGGG trouble since it's used by 300+ people.

So the first thing was to unplug the LAN cable to make sure I'm the only user on the server. Next, patch the web.config file to make sure we see all error details and the stack trace. This can be done by:

Changing the line
<safemode maxcontrols="50" callstack="false"> to
<safemode maxcontrols="50" callstack="true">
And
<customerrors mode="On"> to
<customerrors mode="Off">
(found at http://www.devx.com/dotnet/Article/17518/1954?pf=true)


A CTRL+Refresh inside Internet Explorer finally displayed that WSS was issuing an AccessViolationException in SPRequest..ctor() - that is the default static constructor of that class.

The hotfix from Micosoft for AccessViolationException in KB923028 did not help, but during testing that I found out that WSS raises first an BadImageFormatException before the AccessViolationException. This means that the main cause of the problem is the BadImageFormatException
and the AccessViolationException is only because the COM wrapper of .NET seems to have a bug.


Because of COM+ errors inside event log, it turned out that SPRequest is actually a COM class (GUID {BDEADEE2-C265-11D0-BCED-00A0C90AB50F}) and that it is located inside OWSSVR.DLL. I simply copied this file from our test server that has the same version of WSS running to this server and IT WORKED.

Well, I forgot to plug the cable in again so the server was still offline for 15 more minutes but anyway…

Windows Error Codes Described

How many times did you see an error message with the deceptive text „Error 3“? “Error 2”, anyone? Well, mostly these codes are triggered by internal Windows function that are called from the program that simply fail.

Instead of using some text to describe this error, most coders simply display the error code. Hey coders, I tell you a secret: Most users would prefer to get the description too!

Until all programs also include the error message, see this System Error Codes list on MSDN

Delphi 7 Bug driving me crazy

A strange bug appears inside the Delphi 7 IDE while you are developing. Since it appears normally only at the end of a debugging session, it takes a while to understand what is going on.

The Delphi 7 IDE has a one of the new feature the ability to “dock” several windows together. It not as good as within Visual Studio 2003, but it properly better than anything you had with Delphi 6. However, when you do this and start debugging, everything seems to be normally. But when you end the debugged application, Delphi out of a sudden displays an error message like: “Access violation at address 0052C7DC in module 'coreide70.bpl'. Read of address 000000AC” or “Access violation at address 00xxxx in module 'vcl7.bpl'. Read of address xxxx”. Delphi crashes so badly, that it even does not end the debugged application so the only way to start working with Delphi again is to exit it and start over.

Because you are a developer you think your virus scanner, a lately installed application or your program itself it the cause of this error. BZZZZ! WRONG! This is a big, bad bug inside the Delphi 7 IDE.

For some reasons, Delphi does not like the dogging of Debug windows (like Call Stack, Local Variables etc.) to the Source Code window. If you move these debug windows to an own window (they can all be dogged together in one window) nothing happens. However, if you try to attach only one of these debug windows to the normal source code window, you are out of luck and the bug will appear when the IDE tries to switch back to the normal layout.

You can easily test if you have this bug: Simply switch between the different desktops (the drop-down right from the “Help” menu) without debugging anything. If you see the above noted error message, you are hit be this bug.

To resolve it, first delete the desktop where the crash happens (View -> Desktops -> Delete). Next, recreate it and do not attach any debug window to the source code window. Then save the desktop and try switching again.