Diskeeper 10 Intelliwrite corruption bug

A couple of years ago I blogged about 3rd-party file system filter drivers and how if they're not coded correctly to cope with NTFS alternate streams they will cause all kinds of weird corruption errors to be reported when DBCC CHECKDB is running. At the time I'd only seen the issue a couple of times so thought no more about it until a few weeks ago.

I was settling down to watch a movie with my laptop nearby when I got involved helping fellow-MVP Jonathan Kehayias (blog|twitter). As things progressed it dawned on me that his CHECKDBs were fine using regular database snapshots, but failed using the automatically-created snapshots, which use NTFS alternate streams (see this blog post where I explain about them). The errors produced were as below (borrowed from Jonathan's blog post):

2009-12-10 01:35:44.04 spid75      Error: 17053, Severity: 16, State: 1.
2009-12-10 01:35:44.04 spid75      E:\SQLData\MSSQL.1\DatabaseName.mdf:MSSQL_DBCC16: Operating system error 1784(The supplied user buffer is not valid for the requested operation.) encountered.
2009-12-10 01:35:44.07 spid98      DBCC CHECKDB (DatabaseName) WITH all_errormsgs, no_infomsgs, data_purity executed by Domain\UserName found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 9 seconds.
2009-12-10 01:35:44.45 spid98      Error: 926, Severity: 21, State: 6.
2009-12-10 01:35:44.45 spid98      Database 'DatabaseName' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information. 

Lo-and-behold, it turned out to be a Diskeeper 10 filter driver that had a bug in it. You can read Jonathan's more in-depth recounting of the story on his blog here.

Diskeeper issued a fix a couple of weeks back, and Microsoft Product Support also put out a blog post with some details. Links are:

Hope this doesn't happen to you!

3 thoughts on “Diskeeper 10 Intelliwrite corruption bug

  1. This is completely unrelated to the post – sorry. I have read articles that you and Kimberly (and others) have written on VLF fragmentation but I have not seen an explanation as to why performance can degrade when this phenomenon occurs. In a future post can you detail the perf issues with VLF fragmentation? I suspected at first that maybe new VLF’s are not added contiguously to the existing ones and that a link from the oldest pre-existing VLF to the first newly added one was created, and that this process repeated eventually causing a somewhat costly giant chain of linked VLFs. But since the VLFs are being added to the same chunk where the existing ones reside this explanation does not make sense. Anyhoo – if you get a chance it would be nice to know the details.

    Thanks –

    Mike

  2. It might be just me, but I am noticing severe performance degradation on Windows 8.1 (x64) with Diskeeper 12 when Intelliwrite is enabled. (Of course, it might be a bad interaction with antivirus and other file system filter drivers).

    In brief, when Intelliwrite is enabled, the OS appears to be unable to multitask file writes with other processes, so writing large files causes other applications to stutter and pause for long periods. It would be most interesting to find out if anyone else has observed this.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Some thoughts on courage

(This is also the Ponderings – editorial – in today’s SQLskills newsletter.) I want to start out this post by sincerely thanking everyone who emailed

Explore

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.