Category Archives: Software

Solution for the slow network for Virtual PC on Windows 7

(Note: the following is a long version of the story. If you want the short version, just the solution, skip to the last paragraph below.)

As I wrote before, I use virtual machines extensively to do work on my computer. I used Windows XP Pro as the host OS for several years now, and it worked quite well. I skipped Vista and kept using XP, mainly because it did not seem like Vista would add any significant benefits to my host computer. However, a few months ago, Windows 7 became available, and while testing my products with it, I was so impressed with its speed, stability, the look and feel, that I decided it was time to upgrade my main host computer to Windows 7.

So, a week or so ago, after backing everything up, I took the plunge and installed a fresh copy of Windows 7 Ultimate. It went well, I was happy. Of course the first application I added to it was Virtual PC, because I needed it to run my virtual machines that do the real work for me. It went well, except for a few surprises, such as the new user interface of the Virtual PC console, that looked like a regular folder rather than a separate program. Also, it upgraded the integration components of my virtual machines and as a result it started using the Remote Desktop to display the virtual machine desktop. It added the ability for the virtual machines to recognize the USB drives attached to the host, but at the same time it downgraded the display capability of the virtual machine to display 16-bit colors only, that caused the fonts on the virtual displays not to be anti-aliased quite as nicely as before.

Those were minor things, though, and after trying my virtual machines for a couple of days, I decided I could live with the new version of Virtual PC. One thing did bother me, though: when I tried to browse the shared network folders from within the virtual machines, the browsing was quite slow. Literally, it took a few seconds just to navigate from a directory to a subdirectory. It was especially bad if the directories contained a lot of files. Copying files over the network was painfully slow, too. However, the network was slow only when using it from within the virtual machines. Outside, the network was as fast as it was before: I could browse the virtual machines from my host computer, and connect to other “real” computers from it, the speed was as usual.

I searched the web and found a few reports from people describing the same problem, but no real solution. The only suggestion was to replace the new version of Virtual PC software with the previous one, Virtual PC 2007. Although Microsoft does not officially support Virtual PC 2007 on Windows 7, a few posts I found suggested that it was quite possible to install and use VPC 2007 on Windows 7.

After contemplating it a bit, I decided that having fast network access from within the virtual machines was worth the trouble and did just that: uninstalled the new Virtual PC, and installed the previous VPC 2007 with SP1. The good news was that even though the virtual machines were previously updated with the new version of the integration components, they kept working well with VPC 2007, as before: the full 32-bit colors of the display were available, the old console window was back, and most importantly, the network access was as fast as before.

I was happy for a couple of days, until I noticed a strange problem happening: after using the virtual machines for some time, while switching back and forth between them and the host computer, at some point the virtual machines would stop accepting the TAB and ESC keys. That was a new problem that I did not experience before. Again, I started searching the web for a solution, and found a couple of suggestions, such as the one about creating a local security policy for the file VPCKeyboard.dll, but none of the suggestions worked: after several minutes, the TAB and ESC keys would stop working in the virtual machines (all of them at once), and the only way to restore them was to shut down all virtual machines, and restart the Virtual PC console application. Then work for a few minutes and do the restart again. Needless to say, that was extremely annoying.

Having spent two days trying every possible thing I could come up with, including searching for the updated drivers, reinstalling the virtual machine additions, trying alternative ALT+TAB managers, turning the Aero theme on and off, and so on, I decided that having the slow network was not as bad as it seemed after all. I removed VPC 2007, and reinstalled the new version of Virtual PC software.  The TAB/ESC keys problem went away, the slow network access returned, and I started searching the web for a solution again. Accidentally, I came across of an old Microsoft support article that applied to Virtual PC 2004 and Virtual Server 2005, that mentioned a solution to a problem of a slow network access similar to what I’ve experienced. Out of desperation, I decide to give it a try, and … it worked! I guess, this problem was fixed in VPC 2007, but resurrected in the new version of Virtual PC (the old bugs are had to die, it seems). Anyway, here is what solved the slow network access in Virtual PC for me (from the Microsoft support article , Method 2):

– On the host computer,  backup the Registry, just in case, and then:

– Run Registry Editor (regedit.exe) and select the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

– Create new DWORD value named DisableTaskOffload and set its value to 1.

– Restart the computer.

After I did the above, the network speed from within the virtual machines became as fast as it was before. Hope this helps someone!

Did you know? Our USB Encryption Software can protect any USB flash drive or any other external drive with a password and strong encryption. Try it free for 30 days! Read more…

Is GPL software free as in “free love”?

I was contemplating the other day how to extend AB Commander to make it able to collaborate with several third-party software products. For example, it would be cool to add some support for the 7z files, which are created by the file compressor 7-Zip . It shouldn’t be too difficult, I thought, because 7-Zip is an open source project, I could examine its source code to see how exactly the 7z files are handled, and maybe reuse some of its code in AB Commander?

Not so fast. 7-Zip is licensed under the GPL license, which strictly forbids the re-use of its source code in the non-GPL’d projects. If I want to use some of the GPL’d code in my own software, I need to convert my whole project to the GPL license and open its whole source code, something I don’t want to do.

After thinking some more, I came up with an idea: I’d make a separate module (a plug-in) that would serve as a bridge between my closed-source project and the GPL’d project. I would make the plug-in GPL’d (because it would need to use some of the GPL’d code), and publish its source code.  My closed source project would link to the plug-in, the plug-in would link to the other GPL’d project’s code, and everyone would be happy: the users of AB Commander would get additional software functionality, the plug-in would be GPL’d, and I would keep the source code of AB Commander closed. Pretty smart, huh?

Again, not so fast. Let’s browse through the GPL FAQ, that explains the issues related to linking between proprietary software and the GPL’d software (or, as they put it, “free” software, where “free” is as in “free speech”). For example, the answer to the question Can I release a non-free program that’s designed to load a GPL-covered plug-in? reads “…In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license…“

Huh? I could understand the requirement to GPL any code derived from a GPL’d code, it’s their code and they are free to restrict its re-use anyway they want, but to require two separate modules dynamically linking to each other to be covered by GPL if only one of them is GPL’d? It seems like asking a bit too much. Especially considering that GPL programs have no reservations about linking to proprietary software. Just take any software for Windows, GPL or not, it’s linking to the Microsoft’s proprietory system libraries. Looks like the philosophy of the “free software” is it’s OK to take advantage of the evil and dirty proprietory software, as long as it is not trying to link back to take some advantage of the GPL’d software.

Not fair!

Update: Apparently I am not the only one who thinks so:

http://wpmu.org/wordpress-and-the-gpl/

Another update: Just found the following article with a legal analysis of this very problem, that confirms the “absurdity” of the GPL’s approach to the software plugins:

http://www.law.washington.edu/lct/swp/Law/derivative.html

Quick and dirty way of cleaning the Windows icon cache

When developing my software, sometimes I need to try a few changes to the application icon, to see which image looks better. Unfortunately, replacing the icon within the application file does not make Windows recognize the new icon when displaying a shortcut to the file: it displays the old icon no matter what: pressing the F5 key to refresh the desktop, using the shortcut Properties window to force it to use the new icon, nothing has an effect.

The problem, of course, is the icon cache: turns out that Windows keeps each icon in its memory (the icon cache), and when it needs to draw the icon, it uses the copy from the cache rather than retrieving the icon image from the original application file. It makes Windows draw the icons faster, but the negative side effect is the inability of Windows to detect the change of the icon.

The naïve approach to this problem seems to be to delete the icon cache, and thus force Windows to recreate it from scratch. Browsing the user profile folder (such as C:\Users\Username on Vista, or C:\Documents and Settings\Username on XP) reveals the file named suspiciously IconCache.db (located in the subfolder AppData/Local on Vista or Local Settings\Application Data on XP. Note that this file usually has the SYSTEM and HIDDEN attributes, so you may need to change your Windows folder settings to see this file). However, deleting this file causes no effect: Windows keeps displaying the old icon. (Which is not very surprising, because the very fact that Windows did not stop us from deleting this file kind of tells us that the file was not in use by Windows). Even restarting the computer does not help: Windows simply recreates the IconCache.db file with the old icon in it, and keeps displaying the old icon!

Nevertheless, it is possible to delete the icon cache and force Windows to rebuild it. Turns out, Windows recreates the IconCache.db file when the user logs off from his or her account. When the user logs back on, Windows loads the IconCache.db file back intro its memory. This gives us the idea when could be the proper time to delete the IconCache.db file: when the user is logged off. But how to delete the file if the user is not logged on and there is no way to start Windows Explorer or some other file management tool (such as my AB Commander, sorry for the plug, couldn’t resist :-) ) Easy: log in to another user account (such as the administrator’s one) and delete the IconCache.db file that exists in your own profile (you do use separate accounts for the day-to-day work and for the administrative tasks, do you?) Another way is to log off from your account and then connect to your computer from another computer on your LAN (you do have both a desktop and a laptop, do you? And they can talk to each other over the local network, can they? If not, what are you doing reading this blog? Just kidding…) Anyway, from another networked computer navigate to your profile over the network, delete IconCache.db, then go back to the first computer and log back into your account. This time Windows will recreate its cache and start displaying the new icon.

P.S. There is a couple of other methods of forcing Windows to rebuild the icon cache. For example, in Vista, you can change the size of the desktop icons (by right-clicking on the desktop and using the View menu), and then change it back. Or, if you have Windows XP, open the Display Properties window from Control Panel, select the Appearance tab, and click on Effect. Now change the Use large icons option, click OK, Apply to have it take effect. Then repeat the procedure to change the option back to what it was before.

The advantage of these methods is that you don’t need to log off from your account to rebuild the icon cache. The disadvantage is that Windows may mess up the layout of your icons on the desktop, and you may need to rearrange them after the icon cache is updated.

Making Vista play nice with XP on a network

While testing my software for compatibility with Windows Vista during the last couple of years I’ve noticed that Vista often does not want to play nice with other computers on my LAN. If there are only XP computers connected, everything was fine: they could see each other, I could move files between their shared folders, etc., no problems. However, should I start a computer with Windows Vista on it, more often than not that computer would not connect to others. When that happened in the past, I usually was in the middle of some other work that I did not want to interrupt, so I would just move the files using a USB flash drive and be done with it. When it happened yesterday, however, I was fed up with it and decided to get to the root of the problem.

The problem was, when I opened the Network folder on the Vista computer, I could see all other computers on the same LAN, as it was supposed to be. However, an attempt to open any of them would either present me with a login box (and no user name and password I tried would let me connect to that computer), or an error message would appear saying “Windows cannot access \\DEV. Check the spelling of the name…”, (where DEV is another computer on the LAN running XP) with the error code 0x80070035 “The network path was not found”. Pressing the Diagnose button would result in the message “DEV is not a valid host name”. Which kind of did not make sense because DEV did show up in the Network folder.

I’ve spent a couple of hours googling around and trying every troubleshooting suggestion I could find, like:

  • Is the name of the workroup correct?
  • If Network discovery and File sharing enabled?
  • Is there something to share from the Vista computer (like a folder on its hard drive)?
  • Does turning the firewall temporarily off make a difference?
  • Does rebooting the Vista computer help?

Nothing helped, the Vista computer could not connect to others. After googling some more, I’ve found the solution. (Ironically, it’s a suggestion for the Linux users, but it worked for me, too):

  1. Open the Local Security Policy console (it’s on the Start – Administrative Tools menu)
  2. Navigate to Local Policy – Security Options
  3. Locate the entry named “Network security: LAN Manager authentication level”
  4. Change the value to “Send LM and NTLM responses”

After I did that, the Vista computer magically started to recognize the presence of other computers and connect to them, just like XP computers always did.

What exactly did the policy change do? It allowed Vista to use a less strong network authentication protocol. Why was it necessary? Apparently, my router (Buffalo AirStation) that runs a variation of Linux, does not provide full support for the NTLM authentication. It is it dangerous to allow the LM responses? It would be dangerous if I allowed unknown persons to plug into my LAN and eavesdrop on the traffic (by doing that they could recover my Windows password), but no one but me is connecting to my LAN. I have to make a note to myself: when I upgrade the router, I need to try to turn off the LM responses on all computers and see if my network would work OK.

Hope this helps someone.

Update: (September 8, 2008)

If you have one of the Home editions of Vista that doesn’t come with the Local Security Policy tool, you can change this policy manually with the Registry Editor: navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, and set the REG_DWORD value named LmCompatibilityLevel to 0. This is equivalent to setting the “Send LM and NTLM responses” value as described above.

How to create a shared clipboard and copy and paste text between computers with ease

(It’s been a very busy time here lately: the taxes, a new product that’s almost done, but just can’t quite get finished, and as a result, no spare time for this blog of mine. Dear Subscribers (both of you), I’m very sorry, please don’t give up on me, I’ll try to post more often here in the future. OK, I want to finish my new product first, and then I’ll try to post more often. I promise :-) ).

Anyway, today I’ll write about a neat way of creating a “shared” clipboard on your LAN, to be able to quickly send pieces of text between computers just as easily as pressing Ctrl+C and Ctrl+V.

Not sure what I mean? Suppose you have several computers connected into a LAN, and you need to copy some text on one computer and paste into another, how would you do it? For instance, most of the time I browse the Internet with my laptop. If I encounter a download link to an interesting program, I want to try it, but I don’t want to install it on the laptop itself (I’m very selective about what gets installed where), I want to download it to my test computer and try it out there first. So I need to copy the web address from the web browser running on the laptop, and paste that address into the web browser running on the test computer. If it were the same computer, the procedure would be extremely easy: Ctrl+C, then Ctrl+V, and that’s all. But if I do Ctrl+C on one computer and then Ctrl+V on another one, it does not work the way I want, because the second computer has its own clipboard, independent of the clipboard the first computer has.

To solve this problem, I need to create a “shared” clipboard. In the past I used a little utility called Netclip, that did that for me: it used a shared folder as the storage for the shared clipboard, and whenever I wanted to copy something across the network, I would press Ctrl+Alt+C, to copy, and then moved to the second computer, pressed Ctrl+Alt+V there, and that would paste the result there. It worked well for years, but then Vista came along, and Netclip stopped working with it (and it did not seem like the Netclip developers were around anymore to release a new Vista-compatible version). So I started searching for a replacement, and tried a few other similar utilities, claiming the ability to share the clipboard between several computers. Unfortunately, none of them worked well.

Finally, some time ago I encountered a free tool called AutoHotkey (it’s a pity I did not discover it earlier, it would have saved me quite a lot of keystokes). In a nutshell, Aut0Hotkey enables you to create scripts to be executed when certain keys are pressed. There are plenty of examples at their web site of the scripts doing a lot of different things, check it out!

One of the first things I tried with AutoHotkey was to write a script that would emulate the functionality of the Netclip utility.The idea was as follows: I would set up a shared folder on one my computers that is turned on most of the time. Then I would set up two hot keys, one (Win+C) to copy whatever was currently selected to a file located in the shared folder, and the second key (Win+V) to read information from that file, and paste it into the clipboard.

After looking into the sample AutoHotkey scripts, I came up with the following script to emulate Netclip:

--- begin netclip.ahk ----

path := "\\your_computer\your_shared_folder\netclip.txt"
#C:: ; Win+C

AutoTrim Off  ; Retain any leading and trailing whitespace on the clipboard.

FileDelete, %path%
if (ErrorLevel > 0 ) ; could not delete the file
{
 MsgBox FileDelete failed for %path%
 return
}

Send ^c	; copy whatever it is to the clipboard
FileAppend, %ClipboardAll%, %path%

if (ErrorLevel > 0 ) ; could not write the file
{
 MsgBox FileAppend failed for %path%
 return
}
return

#V::	; Win+V

FileRead, Clipboard, *c %path%

if (ErrorLevel > 0 ) ; could not read the file
{
 MsgBox FileRead failed for %path%
 return
}

Send ^v	; paste whatever it is from the clipboard
return

--- end netclip.ahk ----

To use this script, copy the code between the dashed lines and save it to a text file named netclip.ahk (or whatever you want to name it, but keep its extension .ahk). The only thing that you need to modify in the script is the variable path that contains the location of the shared file to be used for the storage, at the very top of the script. Make sure the shared folder you use for storage is writable from other computers on your LAN.

If you have not done it yet, install AutoHotkey on each computer, and copy the script to each computer, too  (or put it into the shared folder itself). Create a shortcut to the script, and use it whenever you want to activate the shared clipboard. If you want it to be always active, add the shortcut to your Programs – Startup folder.
Now, whenever you want to copy some text to the shared clipboard, select it just as you would for the regular copy, but instead of Ctrl+C press Win+C. To paste it into another computer, go to that computer and instead of the usual Ctrt+V press Win+V. Yes, it’s that easy :-)

It works well for me, I hope it will work just as well for you, too. Happy copy-pasting, bye till next time. I’m off to finish my new product (stay tuned!).

The Hunt For Blue Screen

This story began about 15 months ago, in November 2006. That was the time when Microsoft was getting very close to releasing Windows Vista, and it was the time for me to start getting serious about making sure my applications were compatible with it.

At that time I was using two computers for the development and testing, one with two single-core Intel processors, and another one with one single-core AMD x64 processor. Both were set up for development and testing of my programs: I was using the first one to test the 32-bit versions, and the second one to test the 64-bit editions of my programs. Since many people reported that Vista was more hardware hungry than XP, I thought it was a good occasion for me to also get a more powerful computer that would run Vista reasonably well. So I bought a new Core 2 Duo (dual core) processor, a motherboard to support it (P5L-MX from ASUS), a new video card to support the Aero user interface of Vista, put them together in a spare computer case I had, loaded up Vista Release Candidate on it, and started working on porting my applications to Vista.

It all went well for a while, except every couple of days or so my new powerful computer would once of a sudden “blue screen” and reboot.

After it happened a few times, I fired up WinDbg and loaded a few latest minidumps into it. They indicated that the crashes were happening in the FASTFAT.SYS driver, and the common reason for the errors was IRQL_NOT_LESS_OR_EQUAL, a common reason for a crash caused by a sloppily written device driver. It seemed like a bug in the FASTFAT.SYS driver shipped with the pre-release version of Vista. I decided there was not much I could do but hope that the bug would be fixed in the final (RTM) Vista release.

A couple of months later the RTM release of Vista became available, so I’ve reformatted the hard drive to get rid of the release candidate of Vista, installed a fresh copy of Vista RTM on it, and started using it.

In a day or two the same crashes started to happen again.

Figuring Microsoft would not release a new version of Vista with a buggy version of such an important driver as FASTFAT.SYS, I started looking for another reason. What made it difficult was that the blue screens appeared not very often, sometimes a week would go by and I started to hope I finally found out the reason, but inevitably, it would crash again no matter what I tried. And I tried a plenty:

I vacuumed the inside of the case and reseated the processor and the RAM modules.

The blue screens kept happening.

I ran the memtest program to check the RAM for errors for a few hours, it did not find any problems with the RAM.

The blue screens kept happening.

I installed the SpeedFan program to monitor the temperature of the hardware components. Although it did not show an overheating, I added another fan to the case.

The blue screens kept happening.

I’ve replaced the video card with another one.

The blue screens kept happening.

I’ve bought a new SATA hard drive (previously I was using an old IDE drive), and moved the Vista installation to it.

The blue screens kept happening.

I thought that maybe I got a faulty motherboard, so I bought a new one, this time P5LD2, again from ASUS. I also picked up another Core 2 Duo processor and a new set of RAM modules to go with it. I reinstalled Vista RTM from scratch, and set up my development environment, and started working as usual.

The blue screens kept happening.

As you can see, at that point I already had two computers which were giving me the blue screens every couple of days or so. I ran out of the new theories about the reason for the crashes, and I returned to the one I started with: the bug was probably in the FASTFAT driver of Vista after all, maybe I should have waited till Vista SP1 was out before switching to Vista as my main development platform. I started thinking about switching back to Windows XP. It so happened that at that time (in September 2007) I was locked out of both of my Vista computers by the buggy Genuine Advantage code of Windows Vista (I plan to share that experience of mine in a separate post, later on, stay tuned). That made the decision to switch back to XP real easy.

I was using Windows XP for several years, and never had a problem like that before, so imagine my surprise that after I’ve reinstalled Windows XP on each of my new computers, the blue screens started to happen almost from the day one. As before, they were occurring in the FASTFAT.SYS driver. It made it clear for me that I was blaming Vista in vain, it did not introduce a new bug, or, at least, if the bug was there, it was not Vista-specific.

I started analyzing the similarities between the two new computers, hoping that would give me a clue. They had different motherboards (although from the same manufacturer), slightly different processors, different RAM modules, different video cards, different hard drives (one was using a WD SATA drive, another one a Maxtor IDE drive). I came up with the idea that maybe I got very unlucky and I got two faulty motherboards. Luckily, at that time the built-in network adapter on one of the motherboards died, and I took this opportunity to RMA the motherboard back to ASUS. I got the replacement back in a few days, and installed it.

The blue screens kept happening.

Thinking that getting three faulty motherboards in a row was very unlikely, I started to try other things. Even though my two old computers were plugged in the same UPS device as the new ones and were working just fine, I thought maybe the new computers were more sensitive to the quality of the power they were getting.

I replaced a cheapo generic power supply in one of the new computers with a considerably more expensive and supposedly better one from Antec.

The blue screens kept happening.

I bought a new, more powerful UPS, specifically for use by the new computers.

The blue screens kept happening.

Out of desperation, I started all over and repeated every troubleshooting step I did before, with each of the crashing systems: reseated the modules, replaced the cables, ran the memtest.

The blue screens kept happening.

At that point, about a month ago, I ran out of ideas. I was ready to surrender and just live with it. Or maybe throw out both of the new computers I’ve built and buy a completely new one, and I was seriously contemplating that, when on January 15 it hit me: what that FASTFAT.SYS driver was doing there anyway? All of my hard drives have been formatted with the NTFS file system, I didn’t remember formatting a drive with the FAT or FAT32 system recently. Why would Windows load the FASTFAT driver?

I reviewed the properties of the drives listed in My Computer, and sure enough, there was one of them formatted with the FAT32 system. It was a virtual encrypted drive I created a while back with the TrueCrypt software. I used the drive as a backup place for sensitive files of mine. Periodically, I would burn the image to a DVD-R disc, to make a backup of it. And yes, there was a copy of this image on each of the new computers experiencing the crashes.

I reformatted the encrypted volumes with the NTFS file system.

The blue screens stopped.

It’s been almost a month since I’ve made the last change, and I have not had a single blue screen. Previously, they were happening every couple of days. I’m very confident now that I’ve found the culprit that caused me so much grief. I believe the following list describes the common conditions for the blue screens to occur:

  1. The computer should have a multi-core processor, such as Intel Core 2 Duo.
  2. The computer should have TrueCrypt 4.3a installed, and there should be an encrypted FAT32 volume mounted.

Why do I think the first condition is important? Because previously I was using TrueCrypt with FAT32 virtual drives for several years on the computers that had single-core processors, and never experienced such crashes with them. Only when I switched to the Core 2 Duo processors the crashes started to occur.

I’ve looked through the source code of TrueCrypt 4.3a and noticed that its driver was compiled with the NT_UP switch in its Makefile. This is definitely wrong. It means that the driver was targeted at the uni-processor systems. Since the multi-core processors are essentially multi-processors, defining NT_UP means asking for trouble.

Why did the crashes stopped after I’ve reformatted the encrypted drives with the NTFS file system? I don’t know. Apparently the NTFS file system driver is more robust and can tolerate the imperfect drivers such as the ones compiled with the NT_UP switch. Why didn’t I get crashes with my old two-processor computer? Again, I don’t know. Maybe the old computer was not fast enough for the error conditions to occur so frequently, and when it did crash once in a blue moon, I just dismissed that as something insignificant and did not pay attention to it.

Now, I noticed that a few days ago a new version of TrueCrypt 5.0 had been released. It uses a new driver build procedure, that does not seem to have the NT_UP flag anymore. This is good. However, looking through their support forums it seems like the new version introduced quite a few new bugs. I guess I’ll postpone upgrading to it until version 5.1 comes out. I want to get some rest from the blue screens for awhile :-)

Update: April 15, 2008

A few days ago I decided to try the latest release of TrueCrypt, 5.1a. I reformatted the NTFS encrypted volume back to FAT32 and the blue screens started to occur almost immediately. After two days of bluescreening, I reformatted the volume back to NTFS, and the blue screens stopped. It looks like TrueCrypt 5.1a still causes this problem. HTH.

Update: May 13, 2008

A week ago I started another experiment : connected a spare hard drive about the same size as the TrueCrypt volume I use, formatted the hard drive with the FAT32 system (just like the TrueCrypt volume that was giving me the blue screens), and copied everything from the encrypted volume to that hard drive. Then I dismounted the TrueCrypt volume, and assigned its drive letter to the hard drive I’ve just attached. Restarted the computer and kept using it as before, the only difference was that instead of a FAT32-formatted encrypted volume I was now using a regular FAT32-formatted unencrypted hard drive. A week passed by, no blue screens. Today I copied everything back from the hard drive to the FAT32-formatted TrueCrypt volume, and disconnected the extra hard drive. About an hour later a blue screen occurred. I think that proves conclusively that TrueCrypt is the real culprit behind these blue screens. HTH.

Update: July 16, 2008.

A week ago I’ve installed a new version 6.0a of TrueCrypt. One of the new things in it was an updated device driver with the improved support for the multi-core processors. That gave me the hope that this version might have finally fixed this bug. For a week it was running  smooth, no BSoDs, even though I’ve switched to using a FAT-formatted encrypted volume. I was thinking about reporting success here, but today – boom, blue screen with IRQL_NOT_LESS_OR_EQUAL status in fastfat.sys.  So I’m switching back to the NTFS volume and reporting for now that version 6.0a of TrueCrypt still has not fixed this problem. HTH.

Did you know? Our USB Encryption Software can protect any USB flash drive or any other external drive with a password and strong encryption. Try it free for 30 days! Read more…