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:
- The computer should have a multi-core processor, such as Intel Core 2 Duo.
- 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…
Hey thanks for this writeup! I found your site after suspecting that a BSOD I just got was related to TrueCrypt being open. I suppose this confirms it!
I actually did just install TC 5.0, so we’ll see how that improves things. I tried to use the fat-ntfs convert utility on the mounted drive, but it seems unable to do it! Something about an inconsistency, but chkdsk finds no such issue.
Ryan,
thank you for your comment. I did not use the fat-to-ntfs conversion utility, I just created a fresh ntfs volume and copied files to it, then deleted the old one. Of course, for that to work one must have enough free space on the hard disk, or a spare hard drive.
HTH
Andrei –
No prob. Just to follow-up with you on this (perhaps to others who will follow!), using TC v5a did *not* resolve the BSOD with a FAT32 volume. I had another bomb last night while running firefox (I previously did not have my profile data in the TC volume. I started having the BSODs immediately after moving it there…)
After that I created a new NTFS volume and copied the files over to it. I ran all morning that way and haven’t had a blue screen yet! As a side benefit the new volume uses the faster new style of access in v5.
FYI I haven’t tried out the “encrypt the whole system disk” feature of v5… Looking at some of the troubles in the forums I may wait a bit on this until they get the bugs out. Looks like a really great feature though.
Thanks again for posting this helpful info.
Awesome! Thanks for this write up. I was about to give up. I started having the BSOD in FASTFAT.SYS on my T60 after upgrading to Vista. I bought a new T61 last week and today I started getting the same BSOD again. Really the same as on my T60. Unbelievable.
I already had a support ticket open with Microsoft without a resolution. They only pointed to faulty hardware. But their memory test run fine, though.
I’ll rebuilt my TrueCrypt volumne and let you know.
Ryan: thanks for the information about TC5a, please keep posting here is you discover anything new.
Gunnar: glad my post was of help. Please write here is you can confirm my findings (or not).
Thanks!
Andrei, thanks a lot for the article. The fastfat.sys caused Blue Screen of Death was driving me nuts on my old build. After rebuilt I have not seen for a month and fastfat blue death came back yesterday – 3 BSODs in the last 2 days (and none in the month before). Extensive googling did bring your article.
I do use Truecrypt 5.1a and after reading your article I thought that you have made good point. So I have tried to use
CONVERT letter /FS:NTFS (shell command) on my Truecrypt contained and sure it could not be done! The CONVERT command found some discrepancies.
I was forced to run CHKDSK letter /F first, and only then was able to convert my Truecrypt container to NTFS from FAT32 (no hidden partitions). This converter error message makes me think that something was wrong with FAT32 inside TC container.
I think you nailed it! Since the only drive on my machine with FAT filesystem was TrueCrypt container – and fastfat.sys is used only for FAT file systems, the connection of this problem to the TrueCrypt container/partition seems very logical (after reading your article)
If no blue screens will appear tomorrow I will know for sure that the problem was indeed in FAT32 TrueCrypt container.
I appreciate that you have taken time and wrote this article, it did give some hope to get rid of blue screens of death.
P.S. I would just add that just running CHKDSK /F on the FAT32 container (without converting it to NTFS as I did) from time to time (or when fastfat.sys BSOD happens a lot) might help too.
Thanks
Sergey
Андрей, спасибо большое за статью. Пока точно не знаю, если ошибка повторится, но что-то мне говорит, что твоя догадка о TrueCrypt-e очень близка к истине. Ещё раз спасибо.
Sergey,
thank you for your kind words, I’m glad my article was of some help. If you discover anything new relevant to this problem, please let me know.
Spasibo :-)
Hi,
Thank’s a lot for this indeed study.
I also have BSOD’s from time to time in FastFat.sys and was suspecting TC.
I’ve been using TC from years in my old PC (Athlon 64) on Win XP Pro SP2 and never had a BSOD.
Recently, I changed my system to a new one with an Intel Core Duo 2 (New motherboard, memory, graphic card 8800GT, and new hard disk) and begun to have this BSOD.
I do not make a fresh installation of Win XP Pro SP2 and only made a clone of my old HD.
My TC disk (v5.1a) is also formated in FAT32 and is the only FAT disk in my system and that is why I also suspected the mix Core Duo 2/TC.
I’ll also try to format my TC disk in NTFL and wait…
Thank’s to all here and hope this will solve our problems.
Hi,
I had been using truecrypt on a number of machines for years without problems. When I upgraded to a Dell Latitude D430 (dual core) I got random BSODs and couldn’t figure out what caused it. After reading this article here I’ve stopped using truecrypt on that machine and don’t get any crashes at all. Seems definitely to be a truecrypt – FAT32 issue.
I’ve filed a bug on truecrypt.org – hopefully they get this resolved in one of their next versions.
Thank you so much for this blog! I also found it through extensive Google searches after suspecting TC51a was causing the BSOD. I am also using a ThinkPad T60 as one other commenter mentioned. My TC encrypted volume is a single file on a USB flash drive. The drive’s and encrypted volume’s filesystems are FAT32. I did this mainly to prevent the “pork” of NTFS on a limited media, but also to maintain compatibility with Linux since I use the encrypted volume with XP SP2 and Linux. I guess I’ll have to maintain two TC volumes (bah!) or hope the latest reverse-engineered NTFS driver for Linux can read/write without corruption… :o(
Today I installed TC51a on 1) a Thinkpad T60 – Centrino Core Duo (32 bit CPU) with 32bit XP Pro and 2) a white box with a Intel D972XBX2 m/b, Q6600 quad core (64 bit CPU), Radeon HD2900XT, with 32 bit XP Pro. Then I made FAT32 encrypted volumes. The T60 hasn’t blue screened yet, but to be safe and reduce the frustration I’ll replace the FAT32 with NTFS. The Q6600 blue screens every time I attempt to mount the FAT32 volume. As soon as I click “Mount”. Before I can put anything in it. Instantly.
Do you have Ex2 IFS installed? That turned out to be the problem for me… hope this helps someone.
Andrei,
I’m so glad I came upon this blog ! It gives me hope :)
I have been going through this for a while, but I am using Cryptainer PE V.7.03 with a FAT file system. I’m going to try changing to NTFS and see if my results concur with the result people have been seeing with Truecrypt.
I’ll post a follow up when I determine an outcome.
Thanks again…
Thanks for this blog! I’m having the same problem but my PC has a rather “old” Pentium 4HT.
Seems like hyper threading is also causng a problem. I use NTFS TC volumes but they are stored on a FAT32 formated USB Stick (Corsair Voyager 8G).
I will try to reformat the stick to NTFS and then try again. Will post a message with the results.
Yep, reformatted the stick with NTFS volume type.
Used to get a BSOD as soon as I tried to mount a second TC volume. But I already mounted six now without any problems! Tried it several times (mount/unmount, various sequences, no problems!)
Eggy, thanks for reporting back, glad it worked!
This blog post was dead on (TC 5.1a). Just as a suggestion to others: if you’re able to mount the volume, you can run a chkdsk /f and then a convert /f:NTFS and that will convert it on the fly to NTFS, no need to reformat or create a new volume. I’ve had no problems going on a week now.
Thanks again!
Yesterday evening I created a FAT formated Truecrypt File Container on my UBUNTU machine (Athlon X2). this worked like a dream.
Today I tried to open the container on a Vista Notebook with Core2duo processor. Instantly I got a nice bluescreen !
Truecrypt 6.0a on both machines.
With the UBUNTU Vresion of truecrypt the only format option is FAT – so this is nasty …
Hey, thanks a lot for the Blog! Wanted to say that I think you got it completely right the problem is !TrueCrypt-FAT32! AND !Dual Core! I’ve been using a 2GByte-FAT32 container since 2 years – since version 4.0 and never had an issue on my four single core desktops&laptops.
Since a week i have a new Dell Latitude D530 with Intel Core 2 Duo and I got the BSOD FastFat.sys once a day – even at TC version 6.0a. I will go to convert the FAT32 to NTFS now…
Excellent post, I have just built myself a new quad core dev machine running Vista, I find that Trucrypt 6.0a causes an instant BSOD as soon as a mount is attemted on both FAT32 and NTFS formatted truecrypt volumes. Intersetingly, the Linux verison is fine. I run it routinely with multiple mounted fat32 volumes on a dual core x64 AMD running Fedora 8 with a 64 bit, mp enabled kernel and have no problems, whatever the issue is its specific to windows and multi-core systems. evidently ntfs is better but still not immunie to this, and more cores makes it worse.
Thanx, dude :) This trouble made me seek for a long time. It’s not a big deal – I didn’t use TC very often – but I just know how it happens for now. Did you write somthng ’bout this bug to TC development team?
Pingback: Medienkontor KK » Blog Archive » BSOD/ Absturz mit Truecrypt auf Mehrkernprozessoren unter Fat32 - fastfat.sys
Removing ext2-fs solved my problems.
I’ve had the same problem for about a year now, starting when I bought a new computer. Also tried everything… for no use. Nothing helped.
A few days ago I got a new computer at my work. It started to crash the same way my computer at home. Hm… Strange.
Since I’ve been using an encrypted USB-stick with some portable programs almost all the time, both at home and at work, I started to suspect that it could have something to do with it.
And now I found this blog and recognize everything you write!
And now I think it’s a scandal that Truecrypt doesn’t list this problem as an “Known issue”!
Man, you saved my life!!! (And my job, too!) I use a pendrive for all my personal data, specially e-mails, and I’m running Portable Apps inside a TrueCrypt partition. Since I wanted it as portable as possible, to run on many systems, I decided to format the TrueCrypt volume as FAT32. I was already connecting the bluescreen problem with the pendrive, but I was thinking the problem was with the hardware, not the filesystem itself.
Reading your post, and the fact that TrueCrypt FAT32 volumes were the problem, I can only assume that’s my problem too.
I’ll re-format my crypted volume now and every day without a blue screen I’ll remembrer you and your help….. ;)
Thank you!
Thank you for your post. Turns out the problem totally vanished after un-installing ext2 ifs.
My home-videos (and my girlfriend) appreciate your effort :))
Thx to this site I found my problem… just unistalled that damned ext2 ifs and truecrypt came back to life!!!! (vista x64)
thx again
EXT2FS – got to be it!
TrueCrypt causes pc to bsod on mounting.
Vista 64-bit TrueCrypt (all versions tried) Lenovo ThinkPad T61 Intel dual 4GB RAM
EXT2FS and VISTA 64 That’s IT!!
Get rid of EXT2FS. End of Blue Screen
I’ve had the same BSOD on my office PC a few days ago, same message, same symptoms, when trying to mount a regular Fat32 penDrive. The PC is single core, running WinXP. Yet I have other penDrives in Fat32 that do not crash, so I decided to forget about it. Then I made a file-volume with TrueCrypt today, tried to mount it and blue! So searching on google I found this excellent article, but since the bug happened with a regular volume also I was suspicious of something else.
Then I sow this comment:
#
Removing ext2-fs solved my problems.
By Derek on Sep 2, 2008
I’ve removed the ExtFS2 driver and it’s all running now.
How about new TC 6.1?
I also had BSOD with my FAT32 crypted drive and it is gone with converting to NTFS. Can anybody say something about this new version?
i bsod when system encryption fat32 os, and it’s die, and i from google to here :)
Hi all,
first I have to send many thanks to Andrei for this post. He has saved a lot of hours of my time.
Secondly, I have a bad news to all. I am using TrueCrupt 6.1a on AMD Athlon 64 X2 DualCore, and I have TC FAT32 partition mounted. I have had BSOD (fastfat.sys) nearly 2 times per day.
Right now I’am going to reformat TC partition to NTFS. I really belive it will help, because the symptoms are the same.
it was very helpful for me. thanks a lot
Wow, thanks a million for this writeup. I’ve been searching for the source of these bluescreens for a long time. I was using Truecrypt 4.3 on a USB thumb drive with its partition formatted to FAT32 (same setup as an above poster – PortableApps inside TC). I’ve been using it fine on my laptop for over a year like that. The part that drove me nuts is that I would never get bluescreens on my laptop (it uses an old PentiumM, single-core), but on my desktop at home the same thumb drive would always bluescreen (the desktop is a Core 2 Duo).
I went through the same things you did. I thought for sure I was having USB problems – I’ve already swapped the mainboard. When that didn’t work I figured it must be a bad ram, bad cpu, something hardware related.
Finally an answer to what’s been going on. I’ll have to upgrade the TC install, and if that doesn’t work I guess I’ll have to reformat NTFS. Thanks again!
Of note:
This still occurs with TrueCrypt 6.1a, with a FAT32 volume. Same bluescreens, same fastfat.sys “incriminated”. The system: a core 2 duo (dell d630)
As with many other posters, this was driving me absolutely nuts. I’m a long-time user of TrueCrypt, but I had in quick succession upgraded my laptop to a dual-core and then upgraded my USB drive (formatting a new TrueCrypt volume as FAT32 for speed and compatibility reasons). New laptop kept BSODing, and on top of that my old reliable work machine (also dual-core) suddenly started!
Converting to NTFS right away. You’ve saved me days of tribulation.
I have been seeing spontaneous reboots (no BSOD) on my D630 with TrueCrypt 6.1a, FAT32. I’m reformatting with NTFS now. Thanks for posting this!
I created a new volume with the NTFS filesystem, instead of FAT, and copied all the contents from my previous FAT system to the new one. I hope everything will be fine now. No more BSoD.
Thanks for this post.
Lifesaver! Thanks a million!
I’ve been following this thread for some time now (more than a year).
I’ve had the blue-screen problem consistently since moving to a multi-core machine, with not a lot of joy.
NTFS makes it better, but under heavy IO load, it can still happen.
For me, the culprit was having my Microsoft Outlook .PST file on an encrypted volume. The way Outlook hammers IO nearly guarantees a bluescreen within minutes of opening Outlook once the PST file gets large (>1Gb).
It turns out that if I use the “old” format of PST file rather than the 2003/2007 format (which includes support for unicode), things are a lot better. It’s been stable for me for about a month now (no crashes).
We really need a way to reproduce this phenomenon (blue-screen under high IO load) for the devs to get a hint of what may be wrong. I still think this is a bug in Truecrypt, but other than this blog, I have not seen much coverage.
It would be good to have at least acknowledgment of the problem on the Truecrypt known buglist or even just in the forums.
Note that it was rock solid for me under Ubuntu mounting the same volumes and running XP in VirtualBox to access Outlook (that was my workaround for a while)
Sonny Tham, I also have the BSOD under heavy load, even with NTFS vol. Not so often as with FAT, but BSOD happens…
But I don’t use Outlook at all. For me BSOD comes then I open many sites in Firefox Portable (on TC volume :). It happens only on native dual-core CPU, not on P4 630 with HT :) Sometimes I have 2-3 BSOD per session on Core 2 Duo, sometimes TС looks like stable 2-3 weeks… I cant say definitely what is wrong :(
May be TС 6.2 will show us some improvement ;)
Serj, Sonny Tham: are you sure that the BSoDs you are getting with an NTFS volume are due to TC? I’ve been using a portable drive with an NTFS-formatted TC volume for years, on several different Core 2 Duo PCs, and never had a bluescreen that I could trace to TC. And the volume is used quite heavily, too: I run FireFox and Thunderbird off it, as well as a few Virtual PCs, and other stuff, all the time. If you could send me a couple of minidumps that you think are related the TC crashes (you can find them in the C:\WINDOWS\Minidump directory) I would try to look into them with a debugger and hopefully see something. Please do not send them all, just two or three would be enough. My email is “support (AT) winability.net”. Thanks.
This is an interesting thread.
I’ve been using FAT formatted TC volumes for some time. My PC had a FAT32 C drive, the remaining being NTFS. A couple of months ago I started getting an occasional BSOD on shutdown (around 1 shutdown out of every 35):
IRQL_NOT_LESS_OR_EQUAL
*** STOP: 0x0000000A (0x000000B0, 0x00000002, 0x00000000, 0x8050EEf5)
Despite it being configured to do so, no minidump was produced and no errors appeared in the event log, so it was impossible to diagnose the problem.
I eventually installed a new HD and reinstalled XP SP3 (all non-TC drives now being NTFS). I’ve just had another spontaneous BSOD:
BugCheck 1000007E, {c0000005, b7c304f1, f896ac48, f896a944}
which HAS produced a minidump, analysis of which suggests it’s “Probably caused by : Fastfat.SYS”. I’m wondering if TC has been the problem all along. Since in my previous installation my C drive was FAT32, I’m wondering if a Fastfat.SYS failure may have been responsible for the lack of a minidump or event log entry?
Either way I’ve just changed all my TC volumes to NTFS, and fingers crossed it just may solve the problem.
Altough i came here because i suspect TC as well I do wonder if there might be other reasons. 1) it happened a few times that i shut down my computer without unmounting the TC Volumes or that my laptop went off due to low battery… therefore it might be that this caused an error in the filesystem. 2) I suspect an option that came along with the latest processor generations and which i activated shortly before the first bsod happened- while everything worked fine for half a year without this option. The option i am talking about is the “no execute bit” that came along with amd64 and the latest pentium 4 models. which in fact coincides with other users experience that their first bsod happened on multicore systems.
in case it is the second reason there must be an software error in windows or TC which in combination with the nxBit causes the crash. otherwise there wouldn´t be the reports of linux systems without problems.
i will try the fx of disabling the option instead of converting to nz´tfs and report if it helps solving the issue.
Gah, after half a year with virtually no problems, I had three BSoDs last night from the Truecrypt + Fat32 bug. Now I’m seriously considering using NTFS for my thumb drives.
Well it’s six weeks since I converted all my FAT32 volumes to NTFS, and I’ve not had a BSOD since. So I’m reasonably confident that Truecrypt was the culprit. I should add that whilst I do have hyper-threading, I don’t have a multi-core processor.
THANK YOU. I was killing myself trying to figure out why my dell latitude E6500 laptop kept blue screening over and over and over.
I very recently changed my truecrypt volume to FAT32 on my thumbdrive to make it compatible with some linux grub multiboot stuff. Ever since I did that, I have randomly been getting bluescreens. I’m on the latest (at the time of this writing – 6.2a or something) of truecrypt.
I guess I’ll just buy two thumbrives (one for the multipass) and keep my other drive NTFS for work…
Glad I found your page.
It’s people like you that restore my faith in humanity. A big THANK YOU.
I’m using 6.3a (latest at time of writing) and get the Blues all the time (often 3 a day). I went an awful long way to identify the problem (although not nearly as far as you) so thank you for saving me the time.
I realised it was happening when the thumb was in, and after reading and testing, confirm your diagnosis.
Also very glad I found your page…
I just ran into the dreaded BSoD when mounting a TrueCrypt file container. I have multiple 4.6gb file containers on a local 1TB SATA drive. Each container is formatted with NTFS. I had flawless operation for over a year… until recently. I read this forum and determined another possible cause of a (non-specific) blue screen of death:
Antivirus trying to scan the container file upon a mounting attempt.
I recently renewed my subscription to ESET’s Smart Security 4, and they had a download link to update to v4.2. This was a stand-alone install and not a ‘check for updates’ feature of the application. As it turns out, the FULL install (over a previous one) reset the ‘exclusions’ for the file system scanner. As a result, the previously excluded TrueCrypt containers were now included in file scanning. I simply re-added the containers and their parent folder to the exclusion list and it seems to have corrected the issue. I will post back if any other issues arise.
Again… BSoD can be caused in TrueCrypt v6.2a if you try to mount a local file volume, and that volume is being scanned by any antivirus program.
Add your file-based volumes to your antivirus program’s “exclusion list” so the antivirus does NOT scan the encrypted file container.
I use TC 6.0a (and some previous versions) for whole-disk encryption with an XP SP3. I get also BSOD, and I suspect TC as well. It’s a Dell D630, dual core. The disk is formatted to NTFS, if that matters. No antivirus.