Windows 7 RTM contains a rather nasty chkdsk bug

Windows 7 RTM, which will be distributed to MSDN/TechNet and technical beta testers tomorrow, contains a nasty memory leak when the chkdsk command is initiated.

The bug occurs when the CHKDSK /R command is initiated on a non-system volume. Memory usage of the chkdsk.exe process soars until the system is using over 90% physical memory. In some cases this will cause the system to become unresponsive and unstable.

Some are calling the bug a "show stopper", whilst others (Randall Kennedy) claim it could derail the Windows 7 launch. It's worth noting that Kennedy claimed in November 2008 that Microsoft had delayed the Windows 7 beta to early 2009, even though company officials always stated this was the case. In other words, take his words with a pinch of salt.

Is this a show stopper? No not really. Yes the memory leak is bad but it's a process that is used so rarely that Microsoft would mark this as minor in terms of bugs. There are unconfirmed reports that Windows VP Steven Sinofsky has claimed this is a controller issue and can be fixed with updated drivers, something that Microsoft can push out with Windows Update. In an unverified blog posting, Sinofsky states "In this case, we haven't reproduced the crash and we're not seeing any crashes with chkdsk on teh (sic) stack reported in any measurable number that we could find. We had one beta report on the memory usage, but that was resolved by design since we actually did design it to use more memory. But the design was to use more memory on purpose to speed things up, but never unbounded — we requset (sic) the available memory and operate within that leaving at least 50M of physical memory."

It's worth noting that this bug also affects Windows Server 2008 R2, an operating system that potential customers would be more likely to use the chkdsk tool on. We have asked Microsoft officials for an official statement on the issue and are awaiting their reply.

Report a problem with article
Previous Story

Windows 7 testers to get free copy from tomorrow

Next Story

Apple gets in a mucking fuddle over iPhone dictionary app

104 Comments

Commenting is disabled on this article.

If this is a Chipset driver issue then why is it present on all of my computers when booting from the DVD in WinPE? Also, why do I not have a single computer that doesn't have this issue present considering all of them have the latest driver updates? One last thing, what are Apple Mac users supposed to do about this considering I doubt Apple will release updated chipset drivers for 2 year old Intel MacBooks? Answer those questions and then tell me it's not a show stopper considering none of my computers properly perform this command like Vista did! I also found this issue is present doing the "/r" or "/f" commands.

pilot76103 said,
If this is a Chipset driver issue then why is it present on all of my computers when booting from the DVD in WinPE? Also, why do I not have a single computer that doesn't have this issue present considering all of them have the latest driver updates? One last thing, what are Apple Mac users supposed to do about this considering I doubt Apple will release updated chipset drivers for 2 year old Intel MacBooks? Answer those questions and then tell me it's not a show stopper considering none of my computers properly perform this command like Vista did! I also found this issue is present doing the "/r" or "/f" commands.


What 'issue' is present? RAM Usage? This is by design, when using the /R (which means something is really wrong) it uses as much RAM as it needs depending on your volume size and the amount of files on your computer.

As for the 'crash' that resulted from running chkdsk (a different issue) - it is directly related to a couple of chipset drivers.

1) Chkdsk with /r assumes the user knows there is an emergency and will use as much RAM as needed to get the process completed and not 'shift' data back and forth in virtual memory or other things that could further compromise a failing hard drive.

2) Chkdsk CRASHING is a freaking chipset issue that is a side effect and has NOTHING to do with the RAM usage.

There is a bug here, it is in a few chipset drivers, that are fixed. As for the high RAM usage, this is normal, and WANTED if you have any clue about why the /R option is used and why people would want the process to work.


This whole 'show stopper bug' has become the most insane thing if you step back with some perspective.

1) The original people noticing this have NO FREAKING clue that chkdsk /r is using a lot of RAM for a REASON. so they first think memory leak or problem or bug and then when they find a few chipsets that fail with chkdsk, they assume it is a Win7 problem that is related, when it is just a chipset driver. PERIOD.

Get it YET or do we need to get crayons out for people and some charts?

I'm still thinking this is not a bug. There are only a fre people that had BSOD.
Everyone else (myself included) that wrote their results in the forum thread got the RAM released without any problem.

However, only time will tell as Microsoft addresses this "issue" and make an official statement or something.

it's funny because on build 7600 which seems like the rtm i dont get this bug sure the memory usage goes up to like 180MB of memory and not 100% cpu usage and explorer does not do what the article says it would then chkdsk closes and gives the memory back it used, i think this bug may affect a certain ammount of ppl but perhaps it does not affect me cuzz i applied some internal updates i found but who knows.

The bug that really annoys me is when you go to Device Manager, right-click and do properties of just about anything, then hover your mouse on the red X box like you're going to close the window.

The red box flickers. Not sure if it's simply constantly refreshing info or what, but it's darn annoying. And I encounter it more than chkdsk.

It's by design. It's a feature. It's not a bug. It's supposed to use your RAM. It does not cause a crash.

It's by design. It's a feature. It's not a bug. It's supposed to use your RAM. It does not cause a crash.

It's by design. It's a feature. It's not a bug. It's supposed to use your RAM. It does not cause a crash.

To quote Sinofsky: "Deep breath."

There I feel better.

Now ... I would be a lot more concerned about something called "TWEETDECK" using up over 100MB.
I think I might be embarassed to admit I used such a thing.

Yea after researching this a bit. The function of it using all the ram is normal, and it releases the ram once it is complete. If it causes a blue screen at all, that is related to a controller driver bug.. not an issue with the OS.

BTW the chkdsk /r utility memory usage was changed in the Beta versions to utilize more ram, to help complete the task quicker....

Wow. Well, I'm sure they'll get this resolved through Windows Update. Chkdsk isn't something people use every day. Heck, the average user probably never uses it...

And if the average user does use it it won't effect them since they only have one system partition on their drives. This bug only happens on non-system partitions. And that's a very small percentage of overall windows users.

Lots of people just have C: and nothing else.

An excellent item to start the first patch, after the official release date.
or, at the very least,
The start of SP-1.

While it may not be a very frequently used command, the problem IS a bug, and needs to be fixed. The last thing MS needs is the reputation that Win-7 is buggy!

TsarNikky said,
While it may not be a very frequently used command, the problem IS a bug, and needs to be fixed.

I don't think there is much debate on whether or not this is a bug. The big debate is whether or not this is a "showstopper" bug bad enough to cause MS to stop the distribution of the RTM starting tomorrow to all the MSDN/Technet/freeloading-beta-tester (j/k on that last part!!) peoples and to make them fix it before then. It's not a showstopper bug first of all and it would cost MS way too time/money to have to rebuild the code this late in the game (IMHO). Heaven forbid they bump up the build # simply to fix this and delay it from the people salivating to get their paws on it tomorrow!

If you are scared of chkdsk then stay away until it is fixed. Most people did'nt even know about until now.

I got the memory back when it was finished and it didn't crash the computer. Hell, I only even ran chkdsk on my drive because I read this story.. I never would have found it otherwise.

Funny, on build 7201 x64 I came across a bug (couldn't repeat it) where Explorer.exe took 2GB ram too. Had to kill the process. Not sure what triggered it.

daneel said,
Funny, on build 7201 x64 I came across a bug (couldn't repeat it) where Explorer.exe took 2GB ram too. Had to kill the process. Not sure what triggered it.

Yeah, I have seen this as well. Microsoft actually have a simple bug fix for this one. Stop running explorer.exe

Folks, don't overlook the fact that this only affects non-system partitions. Sure, those of us who read Neowin are the type of people who probably have lots of partitions, but the vast majority of ordinary users and their grandmothers will typically have C: and that's it.

And you people talking about how admins may routinely run chkdsk on servers: They don't routinely run it with /r. At worst, they may use /f but often they will use no switches at all (read-only mode, just to check for possible problems).

As for the fact that the Disk Check tool in the GUI is also affected, it's only affected if you check the checkbox which is equivalent to the /r switch. The default options do NOT have this checkbox checked.

I'd say that the only people likely to be affected are the type of people who will have already heard about this bug by the end of the week, and therefore they will already know how to avoid it until a patch is available.

ok, fair enough, but nobody should have one partition. Everybody should have a OS partition, and a data partition, that way when the OS gets hosed, because of something like this, you don't destroy your data. Or, that if your data gets destroyed, at least you can still play solitaire.

How would the OS getting hosed destroy other data on the same partition? It's perfectly recoverable unless the harddrive is physically damaged, at which point partitioning won't matter. What you should be recommending is a whole second harddrive. Otherwise, users are more than welcome to have only one partition, since splitting one drive to keep data separate is more about convenience than anything else--allowing a clean install of Windows if the desire arises.

cakesy said,
ok, fair enough, but nobody should have one partition. Everybody should have a OS partition, and a data partition, that way when the OS gets hosed, because of something like this, you don't destroy your data. Or, that if your data gets destroyed, at least you can still play solitaire.


Or you could just back up your data. I used to run multiple partitions until I got a home server. Don't really see the need now.

Well... another bug for you. Look at the borders of the CMD windows. Theyre way bigger than the normal borders on any other windows. Check on you own system.

This is an extreme over reaction. It's not like most of us run chkdsk that often.

It's a minor bug that can easily be fixed and won't even be noticed by most people.

In fact this has been a bug since the beta days and you can see that on the many forum posts on the net and it's took 8 months for most people to notice it. What's that tell you?

Driver memory leaks aren't the fault of the application. Sounds like someone is begging for traffic.

Also, what's with TweetDeck using 115MB? Nobody cares that a dinky little desktop app monitoring a website takes that much? Where's the uTorrent crowd?

"After emailing back and forth with the VP Sinofsky, it was found that the chkdsk /r tool is not at fault here. It was simply a chipset controller issue. Please update you chipset drivers to the current driver from your motherboard manufacturer. I did mine, and this fixed the issue. Yes it still uses alot of physical memory, because your checking for physical damage, and errors on the Harddrive your testing. I'm currently completed the chkdsk scan with no BSOD's or computer sluggishness. Feel free to do this and try it for yourselves. Again, there is no Bug."
found on zdnet

please update your news accordingly

Wow, this comes up a lot. And here's the answer, as it is every time: Using memory is NOT A BAD THING, contextually! Using memory is advantageous to speed things along. I only see this as a bug if and only if it causes other processes or the system to fail. And it apparently does not.

Chkdsk is a recovery option only, designed to NOT be used in regular day to day processing. If you're running it, you ABSOLUTELY want it to run as fast and as well as possible.

mram said,
Wow, this comes up a lot. And here's the answer, as it is every time: Using memory is NOT A BAD THING, contextually! Using memory is advantageous to speed things along. I only see this as a bug if and only if it causes other processes or the system to fail. And it apparently does not.

Chkdsk is a recovery option only, designed to NOT be used in regular day to day processing. If you're running it, you ABSOLUTELY want it to run as fast and as well as possible.

And where does "will cause the system to become unresponsive and unstable." fall into your "it's a good thing" point of view?

The problem isn't that it is using the RAM it needs. The problem is that it can friggin lock up your PC. Did you not read the article, and just see "RAM" so decided to post?

RAID 0 said,
What you said may be true, but you don't get the memory back when chkdsk is done. So yeah, it's not good.

I've reproduced the steps on both my desktop (7100) and my laptop (7600). Both exhibited the intended behavior as Steven Sinofsky noted on Chris123NT's blog with no side-effects. The memory is released once chkdsk is done, and the system is also still responsive during and after the operation.

markjensen said,
And where does "will cause the system to become unresponsive and unstable." fall into your "it's a good thing" point of view?

The problem isn't that it is using the RAM it needs. The problem is that it can friggin lock up your PC. Did you not read the article, and just see "RAM" so decided to post? :laugh:


yeah except that it doesn't cause the system to become unresponsive and unstable. Hundreds of people have tried since yesterday, none has experienced crashes. And what would you be doing during a chckdsk /r anyway? you only run that command after a severe hard drive fault, do you want to play crysis while running the command?

This is absolutely a show-stopper and will derail the Windows 7 launch. The reason? Absolutely everyone I know -- including my Grandma -- runs CHKDSK /R on a regular basis and Windows 7 will be unusable without this functionality solidly in place.

People may run 'chkdsk' often, but 'chkdsk /r' is for people looking for bad sectors which take literally hours depending on the disk size.

It's not a show-stopper bug because it can be patched with an update on Windows Update, or, Microsoft could apply the patch during the install of Windows 7 on the DVD (they include the patch on the actually DVD).

Also, VP Sinofsky has said this is a chipset driver issue and not an issue with Windows. But we'll have to see what happens.

Hahahaha.......they should just cancel this release because this is going to be very bad press and Apple will make fun of it.

Tony. said,
People may run 'chkdsk' often, but 'chkdsk /r' is for people looking for bad sectors which take literally hours depending on the disk size.

It's not a show-stopper bug because it can be patched with an update on Windows Update, or, Microsoft could apply the patch during the install of Windows 7 on the DVD (they include the patch on the actually DVD).

Also, VP Sinofsky has said this is a chipset driver issue and not an issue with Windows. But we'll have to see what happens.

I severely doubt this is a 'chipset' issue (and Sinofsky didn't claim so). I'm not debating that it isn't an easy WU but if you think this isn't a Windows issue then you're out of your mind - a Windows application misbehaving on a Windows operating system operating on hardware that could previously run chkdsk fine...

NB: I don't think this is anything close to a showstopper, just clarifying.

chkdsk was running on WindowsXP on boot after moving from FAT32 to NTFS. Unless something similar is happening during the install on Win7...I don't see a big problem. ..

I don't see how this is a show-stopper. If this affects businesses moreso than the home user, shouldn't there be IT staff keeping themselves INFORMED on issues like this and making plans to deploy the patch on day one? The only businesses this will affect are ones with horribly under-qualified IT dweebs.

Joshie said,
I don't see how this is a show-stopper. If this affects businesses moreso than the home user, shouldn't there be IT staff keeping themselves INFORMED on issues like this and making plans to deploy the patch on day one? The only businesses this will affect are ones with horribly under-qualified IT dweebs.

I know, each business should have a fully staff department of about 20-30 people (maybe more if the business is bigger), just to keep track of the bugs with Windows 7. Microsoft recommends this in its update manual. They should work around the clock, in shifts of 16 hours at a time, and only drink iron bru.

Seriously though, what a great excuse for any bug ever. I haven't heard that one before, remember to use it for every bug from now one. Shouldn't you guys have people to stay informed about our bugs? What, do you want them to lose their job?

Hey, that's pretty amazing how you ignored the part where I said show-stopper and turned it around into seeming like I was asking departments to make huge investments in following the entire beta testing process. You should go into politics.

I had no idea that it was above and beyond the expectations we should have for IT staff to keep up with Windows Updates.

where do you go to report bugs in win7 rtm?

I found if you do an install on windows 7 x64, where you can select where you are in stalling to . disk0 , or disk21 etc. If you create a partition (not just click next) but actually click create and then install it to that. It will go through the install but on reboot it doesn't set the partition as active.
I have yet to try this on a 32bit version but i suspect it will do the same.

1) The only way you can have the RTM right now is a leaked build, so good luck reporting that.

2) I am running 7 RC x64, I installed a newly created partition, and I had no troubles.

9:32:04 am PST - October 22nd, Two Thousand and Nine. The planets will align and the magic that is Windows 7 shall take place.

Nothing "show stopping" about this bug. It doesn't prevent an install, prevent the system booting, put it in irrecoverable state, or cause a disruption of the user work flow. The likely-hood that someone is even thinking of using chkdsk is when they're not doing anything with their pc. A simple WU is all that's needed.

Jugalator said,
lol, a server that grinds to a halt and leaves, say, 20 users with 1% CPU power to share doesn't disrupt the work flow?

Since when do admins run chkdsk on a production server while in use?

mscrivo said,
Since when do admins run chkdsk on a production server while in use?

Oh thank god my faith in Neowin sysops is being restored...

mscrivo said,
Since when do admins run chkdsk on a production server while in use?

Also, since when does a memory leak cause CPU usage to spike. And, if I read the article correctly, the OS is requesting the memory, and it is being released if it is available, so it wouldn't actually affect any processes currently running on the box. I can't wait to verify this when I finally get the RTM tomorrow.

omni said,
Oh thank god my faith in Neowin sysops is being restored...

You might run it at 4 in the morning, for a small server. You might take the services offline, run it, and then bring them back online. You shouldn't need to reboot for this.

Do these guys at Microsoft actually test this stuff?

My faith in Neowin sysops imagination is all lost...

Chkdsk /r is the full disk surface check, not just the usual /f filesystem check and repair. The /r command does dick-all other than wasting your time when you're using a hardware RAID controller, leaving its best use for single disks that are failing and haven't been backed up (and any data obtained is likely to be corrupt anyhow). Lord help you if that describes your server.

There's no reason for this to call for a resolution more extreme than a Windows Update.

cakesy said,
You might run it at 4 in the morning, for a small server. You might take the services offline, run it, and then bring them back online. You shouldn't need to reboot for this.

Do these guys at Microsoft actually test this stuff?

My faith in Neowin sysops imagination is all lost...

A small server running on what hardware? Some box you built with $300 spare and threw it in a small business?

Even the lowest end of Dell hardware has hardware raid controllers that render chkdsk /r basically useless in comparison. There's no reason to run a /r in a server environment, on a production server, while it is operational.

Jugalator said,
I think the news about Apple opening an iTunes store in Mexico was indicative of that, not this.

At the same time though, this isn't front page ZOMG news...

Seems like a pretty valid news article to me! This may cause a delay the launch of Windows 7. Although saying that I couldn't be bothered to actually read the entire article so I may be wrong

Intelman said,
Must be a slow news day.

I know, another bug in Windows. Sheesh, if we started reported all of these, we would be here every few minutes. I mean, Windows is a huge project, with a huge code base, and lots of components inter-operating. On top of that, Microsoft keep making changes to the way things work, bugs are something you have got to expect from something this big. Of course, if they cut it down a bit, that would help, make it more like linux with its small kernel. But you are always going to get bugs.

hotdog963al said,
Seems like a pretty valid news article to me! This may cause a delay the launch of Windows 7. Although saying that I couldn't be bothered to actually read the entire article so I may be wrong ;)

If you had "bothered reading the article" you could come to no other conclusion than this is being way blown out of proportion by Randal Kennedy and his ilk. To even be able to use the CHKDSK /R command you will need at least two partitions or drives, one for the system which this command can not be used on because the partition is in use and can only be CHKDSk during a reboot. The second partition or drive must either be unmounted for the command to work or CHKDSK will ask you to unmount the partition first.

In any case this command would only be used if a system drive is in a horrible state of disrepair so the person invoking the command is hardly likely to be using the PC during the CHKDSK repair and the drive is confirmed safe to use again. I would not even call the memory leak a minor bug because hardly any one will ever run into it except the occasional power user or IT person who will probably not even use the PC until the operation is finished.

I think every single person who thought this was a show stopper bug needs to be taken out behind the wood shed and flogged LOL. This is nowhere even remotely a show stopper bug. If this was a bug that happened during a typical install/run of Windows that millions would be affected by, that's closer to a show stopper bug than this. People and the media as usual over-reacting and creating a false hysteria LOL.

Not really. Mozilla has stopped Firefox for pretty "minor" issues, using your scale.

Especially stuff like dataloss is a pretty automatic critical bug, and if this can invoke BSOD's on some machines (and thereby cause data loss), or "just" slow it to a crawl on others, I think it would normally have held the RTM back. But now that it's out, well it becomes a different matter of course. But it is a critical bug, of course.

Jugalator said,
Not really. Mozilla has stopped Firefox for pretty "minor" issues, using your scale.

Especially stuff like dataloss is a pretty automatic critical bug, and if this can invoke BSOD's on some machines (and thereby cause data loss), or "just" slow it to a crawl on others, I think it would normally have held the RTM back. But now that it's out, well it becomes a different matter of course. But it is a critical bug, of course.


Mozilla != Microsoft and Firefox != Windows

Still don't think this a end-all-be-all shut down the presses and halt everything bug. Anyways it's easily taken care of with a Windows Update. At this point it's too costly to re-build the OS.

They should just drop a patch on the day it goes public. I think it's too late now to recall the RTM, re-fix and then re-RTM it considering all the OEMs and other system builders are now using and testing it as they prepare their releases.

I don't think I've used chkdsk since Windows 98/2000 lol.

They can just do what they did with the mp3 bug in beta 1? A 0-day patch. Or since systems aren't shipping yet they can get it out to OEMs to update/streamline into their installs. Or a new build. It's not too late I don't think.

Show stopper? Even with a "What should Microsoft do about this bug?" Poll with the option "Recall/Redistribute RTM Including OEMs, fix the issue, then re-RTM" in the link.... What the hell. Hopefully there will be a fix for this in Windows Update and fixed before public release, just dont go around "CHKDSK /R" or disk checker in Explorer on a non-system volume with your new installation of Windows 7 and you should be fine.

This simply needs to be adressed before the launch, as some sort of 0-day patch via Windows Update.

I mean, forget about chkdsk.exe /r for a while, and see this:

I also verified that the problem exists with the integrated disk check utility in Windows Explorer. When you use this function, explorer.exe starts consuming RAM like it's going out of style, pushing my test system to 98 percent memory utilization in just a few seconds. Worse still, explorer.exe failed to release the RAM when I canceled the disk check, and grew even more despite the fact that the check was now deliberately aborted. My only recourse was to either reboot the system or try to manually kill and restart explorer.exe.

Not only is the GUI disk scanner affected too (which is accessed far more easily), but with an even worse aftermath as well...?

Sure, we thankfully don't run disk checkers as much as before during the FAT32 days that wasn't a journalling file system, but this is still unacceptable in especially corporate environments, and where Windows Server 2008 R2 seem to be affected. The default disk scanner causing a server OS to become unstable...

I first thought that this was understandable if the testers had missed it -- after all, chkdsk /r, that's not all too common... But it seems to be in the integrated disk check utility too!? Wat.

Jebadiah said,
Aren't Integrated Disk Check Utility and chkdsk the same?

They are one just has a GUI front-end but it still calls chkdsk.exe.

To be honest I don't think I have ever used chkdsk on a server install and this could probably be fixed by having OEMs slipstream a hotfix in to their installs -- then upload the slipstreamed to TechNet/etc tomorrow.

Lord Ba'al said,
It's quite a disgrace that such a nasty bug made it into the final Rtm version.

So every peice of software ever released is "a disgrace" too huh?

Every software I can think of has contained major bugs that have only been discovered days/weeks/months after release. Windows 7 is/will be no different.

Yes it's unfortunately that this bug was not detected during the beta, but as others have posted, there are certain sets of circumstances involved here. I tried to duplicate it myself last night on 7100 (the most recent build we testers had access to) and I could not duplicate it. Others suspect it's related to specific types of drive too and could even be a driver issue. So it either appeared in later builds (in which case the beta testers could not have helped) or no tester with the required set of circumstances ever tried to do a chkdsk or disk check.

TCLN Ryster said,
So every peice of software ever released is "a disgrace" too huh?

Every software I can think of has contained major bugs that have only been discovered days/weeks/months after release. Windows 7 is/will be no different.

Yes it's unfortunately that this bug was not detected during the beta, but as others have posted, there are certain sets of circumstances involved here. I tried to duplicate it myself last night on 7100 (the most recent build we testers had access to) and I could not duplicate it. Others suspect it's related to specific types of drive too and could even be a driver issue. So it either appeared in later builds (in which case the beta testers could not have helped) or no tester with the required set of circumstances ever tried to do a chkdsk or disk check.

Umm ever heard of OSX, it's perfect.

artzm said,
Umm ever heard of OSX, it's perfect.


Take your comments elsewhere fanboy they aren't helpful nor true. I experienced this the other day and think it's more in depth then reported on officially. My reason being is I assumed that as I hadn't turned my system off in 6 weeks, I was bound to be bogged by now, so I rebooted and it worked fine, must try it later to see if it reproduces, anyone else experienced it???

cerealfreak said,
Take your comments elsewhere fanboy they aren't helpful nor true. I experienced this the other day and think it's more in depth then reported on officially. My reason being is I assumed that as I hadn't turned my system off in 6 weeks, I was bound to be bogged by now, so I rebooted and it worked fine, must try it later to see if it reproduces, anyone else experienced it???


I got a BSOD 2x last night. Was just looking at Meme database and youtube videoes and had this error occur. I never asked chkdsk to run either and afterwards I ran a utility from BIOS to check the status of my RAM so it appears this is the error reported here. Must have been caused by a recent update as I have been using W7 since Jan and this has not happened before. Really annoying too.

VAVA Mk2 said,
I got a BSOD 2x last night. Was just looking at Meme database and youtube videoes and had this error occur. I never asked chkdsk to run either and afterwards I ran a utility from BIOS to check the status of my RAM so it appears this is the error reported here. Must have been caused by a recent update as I have been using W7 since Jan and this has not happened before. Really annoying too.

Oooh that is nasty I didn;t get BSOD this time but it did hog resources until ended process tree, got the RTM going on a Dell laptop tomorrow for testing so hopefully will be fine, fingers crossed

There is a very simple workaround to this problem.
Before you run chkdsk /r , use another program (ramdisk/vmware that you specify the amount of ram) to use up most of the available memory. Run chkdsk /r, then turn off the ramdisk/vmware instance. Boom, chkdsk will continue to run with the memory it allocated leaving the newly released memory alone.