Recycle Bin Woes: Chomping at the Bit

System Requirements:

  • Windows NT 3.51, 4.0, 2000, XP, 2003

The Problem:

Yes, I admit it, I have hard disks running in my current servers which have been with me almost as long as I have – that either says something about how old I am, or how tragic I am; probably the latter actually.

Ever since I got fed up with it all back in 1999 and had a 9x cull, everything – and I mean everything on my home network has run some form of NT or another, be it 3.51, 4.0, 2000, XP or 2003; even Longhorn (I’m still not calling it “that”).

Having suffered some major server related setbacks in the last week, the short version of a very long and depressing story has been that I’ve needed to reinstall a large number of servers, including two here at home. One of them is a nice cost SCSI320 RAID array that has just been rebuild, but server 3, with its numerous ATA disks, that’s a different story.

Thinking long and hard about it, I can conclude that at least two of the disks would have originally started life as FAT Volumes, and has been slave drives under 98, Millennium, NT4, 2000 Professional, XP Professional, 2000 server and now 2003 server. In between there have been numerous file system changes, back and forward from one to the other through the native conversion tools, or by the modern marvel that is Partition Magic.

The point is, the volumes have had a lot of work done on them, many partition dimension changes, many file system changes and last and not least, many operating system changes. So when it came down to a little impromptu data reorganisation when server 3 was retired from Intranet duties, imagine my surprise when Windows was reporting a completely empty 60GB NTFS partition as using well over 3GB of disk space.

All file systems will have some degree of overhead involved in storing their configuration information, NTFS partitions in particular will always have a certain overhead reserved for the on-disk MFT store. However on a 60GB partition this should be around 95.7MB (100,396,572 bytes) depending upon cluster size. So where has the data gone?

The Fix:

Tragically, this little delight is down to the way in which Windows tracks the recycle bin index for any given volume and every given user account on the system. Every user on the computer is assigned and identified by a GUID value by the SAM when the operating system is installed and when the user account is created. Such a GUID looks like:


Note the ending value of 500, which means this account is almost certainly the system Administrator account in this example.

For each GUID on the system a MFT wrapper is created under the super hidden folder <drive>:\RECYCLER which contains the file system entries for everything that user holds in the recycle bin.
The meaning for this is clear, Windows maintains a per-user recycle bin schema, not a per system. Therefore each user account can populate the recycle bin with whatever information that user deletes, and it remain hidden on the disk.

The trouble is when a volume gets old, the GUID’s easily become stale as operating systems are reinstalled, Active Directory is added and removed, disk’s are moved between systems and the file systems themselves are altered.
In the case of this particular volume, well over 3GB of data was trapped in the recycle bins of a rather large number of long dead user accounts, which unintelligently Windows and successive operating system reinstallations has never picked up upon.

There are two ways to deal with this, the first of which I am not going to go into much detail on.

  1. You can wipe out stray GUID entries from the RECYCLER folders by seizing ownership of the RECYCLER folder and literally deleting the wanted GUID’s. Remember though, the system will let you delete the information from any user account that is currently not loaded. You can check the GUID’s off against the HKU hive in the registry to be certain if they exist.
  2. The second way, and the way that I am advocating is to pull all the data off of the volume and perform a format using Disk Manager. The logic is very simple, not only does it wipe out everything from the disk, and perform a thorough bad sector check/retest & repair, it also will upgrade and reconstruct the NTFS / MFT on the volume.

The volumes in question in my example were all NTFS from NT 4.0, where as the standard has been updated through 2000, XP and 2003 with additional features such as Shadow Copy support and native OS level Indexing service support. I therefore am at pains to imagine what sort of state the MFT on the volume was in with all the in-place bolt-on’s added by successive Windows releases, not to mention MFT file fragmentation. Formatting the volume will therefore naturally clean the entire nightmare up quite eloquently.

URLScan 2.5 has a Broken Display Icon in the Add/Remove Programs list under Windows 2000 / XP

System Requirements:

  • Windows 2000
  • Windows XP
  • Internet Information Services 5.0
  • Internet Information Services 5.1

The Problem:

This is nothing more than a cosmetic faux pas by Microsoft which bugs me, so if like me you cannot stand disarray in your Add / Remove Programs, this is the (largely pointless) fix for you!

URLScan 2.5 is an updated version of the HTTP filter released to add something resembling some security control to Microsoft Internet Information Services 4.0, 5.0 and 5.1 – by version 6.0 they have supposedly got security down to a fine art…

When the installer was built someone at Microsoft made a mistake in the uninstall routine strings for Add / Remove programs and as a result, the URLScan 2.5 entry looks thus:

Add / Remove Programs faux pas for URLScan 2.5

The error technically exists under NT 4.0 and IIS 4.0, however as NT 4.0 doesn’t draw icons in Add / Remove Programs, the fix is not going to make any difference anyway.

The Fix:

… I told you it was trivial.

The fix is, however, as equally trivial as the problem. Pull up Regedit and travel to:


Alter the value of the DisplayIcon string from:

to read:

Hit F5 in Add / Remove Programs and there you have it, a working Icon.

Updated release of Microsoft IIS Lockdown 2.1 to include URLScan 2.5

System Requirements:

  • Windows NT 4.0 SP6a
  • Windows 2000
  • Windows XP
  • Internet Information Services 4.0
  • Internet Information Services 5.0
  • Internet Information Services 5.1

The Problem:

Microsoft released the very useful (and necessary) IIS Lockdown 1.0 in August 2001, and updated it to version 2.1 in the November of the same year, adding support for IIS 5.1 and bundling the URLScan 6.0.3547.0 filter ISAPI extension.

The URLScan component was updated to URLScan 2.5 (6.0.3615.0) in an unceremonious fashion in May 2003 to provide an updated ISAPI and, presumably, some IIS 6 support.

It’s not easy to even find URLScan 2.5 in the Microsoft download centre, but it is there, appearing in the search listings as “Setup.exe”.

If you want to bring a new Windows NT4/5.x Server box up to spec you will invariably use IIS Lockdown, which will install URLScan 6.0.3547.0, restart the IIS Services (or restart in the case of NT4). Bring the system backup, uninstall the IIS Lockdown URLScan, repeat the service restart and finally install URLScan 2.5 and – you guessed it – restart the services a third time.

The Fix:

My theory is “why bother” with that, I just reintegrated the new 2003 version of URLScan into the IIS Lockdown 2.1 installer and voila one install, one service reset, give yourself a pat on the back and go make a cup of tea.

IIS Lockdown 2.1.1 C:Amie Edition : Download : 193KB

If you don’t believe it works, the server you are connecting too right now is using it! (assuming this is still a Windows 2000 Server when you read this).

What is new in URLScan 2.5?

Good question, there isn’t any documentation on the 2.5 release (the readme in my 2.1.1 redist is the original version’s). The default configuration script has been expanded with some new variables.

You can now control how and where URLScan logs too – useful as the original version dumps logs in the Inetsrv\URLscan folder in a rather untidy manner.

LogLongUrls=0 If 1, then up to 128K per request can be logged.
If 0, then only 1k is allowed.
LoggingDirectory can be used to specify the directory where the
log file will be created. This value should be the absolute path
(ie. c:\some\path). If not specified, then UrlScan will create
the log in the same directory where the UrlScan.dll file is located.

A new query string control and maximum file request is also a new feature, allowing you to prevent people from sucking the life out of a persistent HTTP connection.

The entries in this section impose limits on the length of allowed parts of requests reaching the server.
It is possible to impose a limit on the length of the value of a specific request header by prepending “Max-” to the name of the header. For example, the following entry would impose a limit of 100 bytes to the value of the ‘Content-Type’ header: Max-Content-Type=100
To list a header and not specify a maximum value, use 0 (ie. ‘Max-User-Agent=0’). Also, any headers not listed in this section will not be checked for length limits.There are 3 special case limits:
– MaxAllowedContentLength specifies the maximum allowed numeric value of the Content-Length request header. For example, setting this to 1000 would cause any request with a content length that exceeds 1000 to be rejected. The default is 30000000.
– MaxUrl specifies the maximum length of the request URL, not including the query string. The default is 260 (which is equivalent to MAX_PATH).
– MaxQueryString specifies the maximum length of the query string. The default is 4096.

Mesh 2200T (Clevo 2200T) only operates in PIO4 disk access mode

System Requirements:

  • Windows 2000
  • Windows XP
  • SIS 630 / 720 Chipset

The Problem:

Yep, it is another ones of those Clevo / Kapok issues! This one was a client’s problem from September 2004 that they were rather desperate to have resolved, and yet no one could come up with an answer.

Essentially the problem boils down to sub-standard performance from the system, which is painfully noticeable at boot time when the system has a lot of disk activity. The reason why this happens is because Windows gets confused with the BIOS/Chipset firmware disk access mode instructions, cannot safely assume it can use Direct Memory Access for data transfer and so gets locked into the processor intensive PIO (mode 4) to do anything.

As usual, this is the result of a badly written set of BIOS firmware.

The Fix:

The 2200T uses an anarchic Phoenix core (1.00.03 10/22/97) with the usual set of extensions to make the modern hardware interconnects work correctly. Before continuing you need to ensure that the Firmware build for the BIOS (this isn’t the core 1997 date) is at the highest possible level; this I believe to be 1.17 built on 28/10/2002.

I am also aware that there is a 1.00.04 core version available in some quarters. I am not able to state the impact of any of these changes on this core. I provide no support or warranty for using the BIOS files below. User them at Your Own Risk.

Version Date Changelog




1. Recognize PIII 1.13GHz CPU (Tualatin core).
2. Support system memory up to 1GB.



1. Solve the error message under Windows XP event viewer.


1. Support “Fn+F6” function key for some NON DDC external display device.


1. Fix the CD-ROM boot failed sometimes problem for TEAC DW-28E and Samsung SN-608.

Windows Registry Fix:

If you reinstall your system at this point, you may have an XP compatible BIOS, however it will still come up in PIO mode 4. It is SIS who actually came up with a solution for this problem, which is known under Windows 2000 on the iS530/620/630/540 chipset’s.

The fix dupes Windows 2000/XP into using UDMA on the hard disk channels. It isn’t what I would call an ideal solution, however it does at least get the computer moving again.

You can download the SIS DMA fix here: (67KB)
All the program is doing is making registry changes on the system. Once you have run the .exe you need to restart the computer before it will come up using DMA.


Flash Utility OEM String Syntax:

The information below has been placed here for reference purposes and is not directly related to the Fix.

FP /N=OEMName[,HotlineNo] BIOSFileName
FP /O=OEMName[,HotlineNo] BIOSFileName

Note :

  1. The maximum length of OEMName is 16.
  2. The OEMName is case sensitive.
  3. The system manufacturer name read from DMI BIOS interface is OEMName padded with blanks(ASCII 20h) and the length of OEMName+blanks is 16.
  4. If you need space character for OEMName and HotlineNo, Replace it with a special character “^”.
  5. After flash the BIOS, turn power off and turn it on, then you can see the OEMName by using the DEBUG command as following :
    -D F000:1C00
  6. Some valid examples:
    a.The hotline number for “Test Computer” company is
    123 4567 890. Then the usage for FP is as following:FP /N=Test^Computer,123^4567^890 BIOS.BIN

    b.The hotline number for “MyComputer” company is
    123-4567-890. Then the usage for FP is as following :

    FP /N=MyComputer,123-4567-890 BIOS.BIN

    c.To disable OEMName and HotlineNo : (FP v1.41 or later)


  7. /O option will disable the OEMName string display during BIOS POST.