Mark S. Rasmussen improve.dk
Feb 04
2014

I’m happy to announce that I’ll be presenting at SQLSaturday #275 in Copenhagen on March 29th!

I’ll be presenting my Recovering Data from Fatally Corrupt Databases session:

Imagine the worst case scenario: Your database won’t come online. Lots of checksum errors logged. DBCC CheckDB won’t even run on the database. And worst of all – you have no backups! Now what do you do with this 20GB binary blob of an MDF file? In this demo-rich session I will briefly introduce the internals of MDF files while primarly concentrating on how to manually extract data from corrupt databases. I will be using the OrcaMDF RawDatabase framework to do most of the parsing, which will also be explained during the session.

If you want to be able to save the day when all other options are exhausted, you shouldn’t miss this session.

Nov 06
2013

In this post I want to walk through a number of SQL Server corruption recovery techniques for when you’re out of luck, have no backups, and the usual methods don’t work. I’ll be using the AdventureWorksLT2008R2 sample database as my victim.

A Clean Start

To start out, I’ve attached the downloaded database and it’s available on my SQL Server 2008 R2 instance, under the name of AWLT2008R2.

A

To ensure we’ve got a clean start, I’ll run DBCC CHECKDB with the DATA_PURITY flag set, just to make sure the database is OK.

DBCC CHECKDB (AWLT2008R2) WITH ALL_ERRORMSGS, DATA_PURITY
DBCC results for 'AWLT2008R2'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
DBCC results for 'sys.sysrscols'.
There are 805 rows in 9 pages for object "sys.sysrscols".
DBCC results for 'sys.sysrowsets'.
There are 125 rows in 1 pages for object "sys.sysrowsets".
DBCC results for 'SalesLT.ProductDescription'.
There are 762 rows in 18 pages for object "SalesLT.ProductDescription".
...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'AWLT2008R2'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Enter Corruption

As I don’t want to kill my disk drives just to introduce corruption, I’ll be using OrcaMDF’s Corruptor class instead. First up we need to shut down SQL Server:

SHUTDOWN WITH NOWAIT
Server shut down by NOWAIT request from login MSR\Mark S. Rasmussen.
SQL Server is terminating this process.

Once the instance has been shut down, I’ve located my MDF file, stored at D:\MSSQL Databases\AdventureWorksLT2008R2.mdf. Knowing the path to the MDF file, I’ll now intentially corrupt 5% of the pages in the database (at a database size of 5,312KB this will end up corrupting 33 random pages, out of a total of 664 pages).

Corruptor.CorruptFile(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf", 0.05);

At this point I have no idea about which pages were actually corrupted, I just know that 33 random pages just got overwritten by all zeros.

Uh Oh

After restarting the SQL Server instance and looking at the tree of databases, it’s obvious we’re in trouble…

A

Running DBCC CHECKDB doesn’t help much:

DBCC CHECKDB (AWLT2008R2) WITH ALL_ERRORMSGS, DATA_PURITY
Msg 926, Level 14, State 1, Line 1
Database 'AWLT2008R2' cannot be opened. It has been marked SUSPECT by recovery.
See the SQL Server errorlog for more information.

What does the errorlog say?

  • Starting up database ‘AWLT2008R2′.
  • 1 transactions rolled forward in database ‘AWLT2008R2′ (13). This is an informational message only. No user action is required.
  • Error: 824, Severity: 24, State: 2.
  • SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:2; actual 0:0). It occurred during a read of page (1:2) in database ID 13 at offset 0×00000000004000 in file ‘D:\MSSQL Databases\AdventureWorksLT2008R2.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
  • Error: 3414, Severity: 21, State: 1.
  • An error occurred during recovery, preventing the database ‘AWLT2008R2′ (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
  • CHECKDB for database ‘AWLT2008R2′ finished without errors on 2013-11-05 20:02:07.810 (local time). This is an informational message only; no user action is required.
  • Recovery is complete. This is an informational message only. No user action is required.

This is officially not good. Our database failed to recover and can’t be put online at the moment, due to I/O consistency errors. We’ve also got our first hint:

incorrect pageid (expected 1:2; actual 0:0)

What this tells us is that the header of page 2 has been overwritten by zeros since SQL Server expected to find the value 1:2, but found 0:0 instead. Page 2 is the first GAM page in the database and is an essential part of the metadata.

SQL Server also wisely told us to either fix the errors or restore from a known good backup. And this is why you should always have a recovery strategy. If you ever end up in a situation like this, without a backup, you’ll have to continue reading.

DBCC CHECKDB

SQL Server recommended that we run a full database consistency check using DBCC CHECKDB. Unfortunately, given the state of our database, DBCC CHECKDB is unable to run:

DBCC CHECKDB (AWLT2008R2) WITH ALL_ERRORMSGS, DATA_PURITY
Msg 926, Level 14, State 1, Line 1
Database 'AWLT2008R2' cannot be opened. It has been marked SUSPECT by recovery.
See the SQL Server errorlog for more information.

In some cases you may be able to force the database online, by putting it into EMERGENCY mode. If we could get the database into EMERGENCY mode, we might just be able to run DBCC CHECKDB.

ALTER DATABASE AWLT2008R2 SET EMERGENCY
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect pageid
(expected 1:16; actual 0:0). It occurred during a read of page (1:16) in database
ID 13 at offset 0x00000000020000 in file 'D:\MSSQL Databases\AdventureWorksLT2008R2.mdf'.
Additional messages in the SQL Server error log or system event log may provide more
detail. This is a severe error condition that threatens database integrity and must
be corrected immediately. Complete a full database consistency check (DBCC CHECKDB).
This error can be caused by many factors; for more information, see SQL Server
Books Online.

Even worse, it seems that page 16 has also been hit by corruption. Page 16 is the root page of the sysallocunits base table, holding all of the allocation unit storage metadata. Without page 16 there is no way for SQL Server to access any of its metadata. In short, there’s no way we’re getting this database online!

Enter OrcaMDF

The OrcaMDF Database class won’t be able to open the database, seeing as it does not handle corruption very well. Even so, I want to try anyway, you never know. First off you’ll have to shut down SQL Server to release the locks on the corrupt MDF file.

SHUTDOWN WITH NOWAIT

If you then try opening the database using the OrcaMDF Database class, you’ll get a result like this:

var db = new Database(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
Capture

Interestingly the Database class didn't puke on the boot page (ID 9) itself, so we know that that one's OK, at least. But as soon as it hit page 16, things started to fall apart - and we already knew page 16 was corrupt.

RawDatabase

While the OrcaMDF Database class can't read the database file either, RawDatabase can. RawDatabase doesn't care about metadata, it doesn't read anything but what you tell it to, and as a result of that, it's much more resilient to corruption.

Given that we know the corruption has resulted in pages being zeroed out, we could easily gather a list of corrupted pages by just searching for pages whose logical page ID doesn't match the one in the header:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf")
db.Pages
  .Where(x => x.Header.PageID != x.PageID)
  .Select(x => x.PageID)
  .ToList()
  .ForEach(Console.WriteLine);
2
4
5
16
55
...
639
649
651
662
663

This is only possible since we know the corruption caused pages to be zeroed out, so you'll rarely be this lucky. However, sometimes you may be able to detect the exact result of the corruption, thus enabling you to pinpoint the corrupted pages, just like we did here. However, this doesn't really help us much - all we have now is a list of some page ID's that are useless to us.

Getting a List of Objects

For this next part we'll need a working database, any database, on an instance running the same version that our corrupted database this. This could be the master database - literally any working database. First you'll want to connect to the database using the Dedicated Administrator Connection. Connecting through the DAC allows us to query the base tables of the database.

The base table beneath sys.tables is called sys.sysschobjs, and if we can get to that, we can get a list of all the objects in the database, which might be a good start. Having connected to the working database, we can get the sys.sysschobjs details like so:

SELECT * FROM sys.sysschobjs WHERE name = 'sysschobjs'
Capture

The only thing I'm looking for here is the object id, provided by the id column. In contrast to all user tables, the system tables have their actual object id stored in the page header, which allows us to easily query for pages by their id. Knowing sys.sysschobjs has ID 34, let's see if we can get a list of all the pages belonging to it (note that the .Dump() method is native to LinqPad - all it does is to output the resulting objects as a table):

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
db.Pages
  .Where(x => x.Header.ObjectID == 34)
  .Dump();
Capture

Now that we have a list of pages belonging to the sys.sysschobjs table, we need to retrieve the actual rows from there. Using sp_help on the working database, we can see the underlying schema of sys.sysschobjs:

sp_help 'sys.sysschobjs'
Capture

Once we have the schema of sys.sysschobjs, we can make RawDatabase parse the actual rows for us, after which we can filter it down to just the user tables, seeing as we don't care about procedures, views, indexes and so forth:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 34 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.Int("id"),
	RawType.NVarchar("name"),
	RawType.Int("nsid"),
	RawType.TinyInt("nsclass"),
	RawType.Int("status"),
	RawType.Char("type", 2),
	RawType.Int("pid"),
	RawType.TinyInt("pclass"),
	RawType.Int("intprop"),
	RawType.DateTime("created"),
	RawType.DateTime("modified")
});
 
rows.Where(x => x["type"].ToString().Trim() == "U")
	.Select(x => new {
		ObjectID = (int)x["id"],
		Name = x["name"]
	}).Dump();
Capture

We just went from a completely useless suspect database, with no knowledge of the schema, to now having a list of each user table name & object id. Sure, if one of the pages belonging to sys.syschobjs was corrupt, we'd be missing some of the tables without knowing it. Even so, this is a good start, and there are ways of detecting the missing pages (we could look for broken page header references, for example).

Getting Schemas

As we saw for sys.sysschobjs, if we are to parse any of the user table data, we need to know the schema of the tables. The schema happens to be stored in the sys.syscolpars base table, and if we lookup in sys.sysschobjs for 'sys.syscolpars', we'll get an object ID of 41. As we did before, we can get a list of all pages belonging to sys.syscolpars:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
db.Pages
  .Where(x => x.Header.ObjectID == 41)
  .Dump();
Capture

By looking up the schema of sys.syscolpars using sp_help, in the working database, we can parse the actual rows much the same way:

// Parse sys.syscolpars
var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 41 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.Int("id"),
	RawType.SmallInt("number"),
	RawType.Int("colid"),
	RawType.NVarchar("name"),
	RawType.TinyInt("xtype"),
	RawType.Int("utype"),
	RawType.SmallInt("length"),
	RawType.TinyInt("prec"),
	RawType.TinyInt("scale"),
	RawType.Int("collationid"),
	RawType.Int("status"),
	RawType.SmallInt("maxinrow"),
	RawType.Int("xmlns"),
	RawType.Int("dflt"),
	RawType.Int("chk"),
	RawType.VarBinary("idtval")
});
 
rows.Select(x => new {
	ObjectID = (int)x["id"],
	ColumnID = (int)x["colid"],
	Number = (short)x["number"],
	TypeID = (byte)x["xtype"],
	Length = (short)x["length"],
	Name = x["name"]
}).Dump();
Capture

Recovering the Customer Table Schema

While there are 12 tables, none are probably more important than the Customer table. Based on parsing the sys.sysschobjs base table, we know that the customer table has an object ID of 117575457. Let's try and filter down to just that object ID, using the code above:

rows.Where(x => (int)x["id"] == 117575457).Select(x => new {
	ObjectID = (int)x["id"],
	ColumnID = (int)x["colid"],
	Number = (short)x["number"],
	TypeID = (byte)x["xtype"],
	Length = (short)x["length"],
	Name = x["name"]
}).OrderBy(x => x.Number).Dump();
Capture

Running the following query in any working database, we can correlate the TypeID values with the SQL Server type names:

SELECT
	*
FROM
	sys.types
WHERE
	system_type_id IN (56, 104, 231, 167, 36, 61) AND
	system_type_id = user_type_id
Capture

Using the output from syscolpars and the type names, we can now deduce the schema of the Customer table (note that the syscolpars lengths are physical, meaning a length of 16 for an nvarchar column means a logical length of 8):

CREATE TABLE Customer (
	CustomerID int,
	NameStyle bit,
	Title nvarchar(8),
	FirstName nvarchar(50),
	MiddleName nvarchar(50),
	LastName nvarchar(50),
	Suffix nvarchar(10),
	CompanyName nvarchar(128),
	SalesPerson nvarchar(256),
	EmailAddress nvarchar(50),
	Phone nvarchar(25),
	PasswordHash varchar(128),
	PasswordSalt varchar(10),
	rowguid uniqueidentifier,
	ModifiedDate datetime
)

All we need now is to find the pages belonging to the Customer table. That's slightly easier said than done however. While each object has an object ID, as can be verified using sys.sysschobjs, that object ID is not what's stored in the page headers, except for system objects. Thus we can't just query for all pages whose Header.ObjectID == 117575457, as the value 117575457 won't be stored in the header.

Recovering the Customer Allocation Unit

To find the pages belonging to the Customer table, we'll first need to find the allocation unit to which it belongs. Unfortunately we already know that page 16 is corrupt - the first page of the sys.sysallocunits table, containing all of the metadata. However, we might just be lucky enough for that first page to contain the allocation units for all of the internal tables, which we do not care about. Let's see if there are any other pages belonging to sys.sysallocunits:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
db.Pages
  .Where(x => x.Header.ObjectID == 7)
  .Dump();
Capture

There are 5 other pages available. Let's try and parse them out so we have as much of the allocation unit data available, as possible. Once again we'll get the schema from the working database, using sp_help, after which we can parse the remaining rows using RawDatabase. By looking up 'sysallocunits' in sysschobjs, we know it has an object ID of 7:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 7 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.BigInt("auid"),
	RawType.TinyInt("type"),
	RawType.BigInt("ownerid"),
	RawType.Int("status"),
	RawType.SmallInt("fgid"),
	RawType.Binary("pgfirst", 6),
	RawType.Binary("pgroot", 6),
	RawType.Binary("pgfirstiam", 6),
	RawType.BigInt("pcused"),
	RawType.BigInt("pcdata"),
	RawType.BigInt("pcreserved"),
	RawType.Int("dbfragid")
});
 
rows.Select(x => new {
	AllocationUnitID = (long)x["auid"],
	Type = (byte)x["type"],
	ContainerID = (long)x["ownerid"]
}).Dump();
Capture

By itself, we can't use this data, but we'll need it in just a moment. First we need to get a hold of the Customer table partitions as well. We do so by looking up the schema of sys.sysrowsets using sp_help, after which we can parse it. Looking up 'sysrowsets' in sysschobjs, we know that sys.sysrowsets has an object ID of 5:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 5 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.BigInt("rowsetid"),
	RawType.TinyInt("ownertype"),
	RawType.Int("idmajor"),
	RawType.Int("idminor"),
	RawType.Int("numpart"),
	RawType.Int("status"),
	RawType.SmallInt("fgidfs"),
	RawType.BigInt("rcrows"),
	RawType.TinyInt("cmprlevel"),
	RawType.TinyInt("fillfact"),
	RawType.SmallInt("maxnullbit"),
	RawType.Int("maxleaf"),
	RawType.SmallInt("maxint"),
	RawType.SmallInt("minleaf"),
	RawType.SmallInt("minint"),
	RawType.VarBinary("rsguid"),
	RawType.VarBinary("lockres"),
	RawType.Int("dbfragid")
});
 
rows.Where(x => (int)x["idmajor"] == 117575457).Select(x => new {
	RowsetID = (long)x["rowsetid"],
	ObjectID = (int)x["idmajor"],
	IndexID = (int)x["idminor"]
}).Dump();
Capture

By filtering down to just the Customer table's object ID, we've now got the three partitions that belongs to the table - one for each allocation unit type - ROW_OVERFLOW_DATA (3), LOB_DATA (2) and IN_ROW_DATA (1). We don't care about LOB and SLOB for now, all we need is the IN_ROW_DATA partition - giving us a RowsetID value of 72057594039697408.

Now that we have the RowsetID, let's lookup the allocation unit using the data we got from sys.sysallocunits earlier on:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 7 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.BigInt("auid"),
	RawType.TinyInt("type"),
	RawType.BigInt("ownerid"),
	RawType.Int("status"),
	RawType.SmallInt("fgid"),
	RawType.Binary("pgfirst", 6),
	RawType.Binary("pgroot", 6),
	RawType.Binary("pgfirstiam", 6),
	RawType.BigInt("pcused"),
	RawType.BigInt("pcdata"),
	RawType.BigInt("pcreserved"),
	RawType.Int("dbfragid")
});
 
rows.Where(x => (long)x["ownerid"] == 72057594039697408).Select(x => new {
	AllocationUnitID = (long)x["auid"],
	Type = (byte)x["type"],
	ContainerID = (long)x["ownerid"]
}).Dump();
Capture

Recovering the Customers

Now that we have the allocation unit ID, we can convert that into the object ID value, as stored in the page headers (big thanks goes out to Paul Randal who was kind enough to blog about the relationship between the allocation unit ID and the page header m_objId and m_indexId fields):

var allocationUnitID = 72057594041270272;
var indexID = allocationUnitID >> 48;
var objectID = (allocationUnitID - (indexID << 48)) >> 16;
 
Console.WriteLine("IndexID: " + indexID);
Console.WriteLine("ObjectID: " + objectID);
IndexID: 256
ObjectID: 51

Now that we have not only the object ID, but also the index ID, we can easily get a list of all the pages belonging to the Customer table:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
db.Pages
  .Where(x => x.Header.ObjectID == 51 && x.Header.IndexID == 256)
  .Dump();
Capture

And since we already know the schema for the Customer table, it's a simple matter of making RawDatabase parse the actual rows:

var db = new RawDatabase(@"D:\MSSQL Databases\AdventureWorksLT2008R2.mdf");
var pages = db.Pages.Where(x => x.Header.ObjectID == 51 && x.Header.IndexID == 256 && x.Header.Type == PageType.Data);
var records = pages.SelectMany(x => x.Records).Select(x => (RawPrimaryRecord)x);
var rows = RawColumnParser.Parse(records, new IRawType[] {
	RawType.Int("CustomerID"),
	RawType.Bit("NameStyle"),
	RawType.NVarchar("Title"),
	RawType.NVarchar("FirstName"),
	RawType.NVarchar("MiddleName"),
	RawType.NVarchar("LastName"),
	RawType.NVarchar("Suffix"),
	RawType.NVarchar("CompanyName"),
	RawType.NVarchar("SalesPerson"),
	RawType.NVarchar("EmailAddress"),
	RawType.NVarchar("Phone"),
	RawType.Varchar("PasswordHash"),
	RawType.Varchar("PasswordSalt"),
	RawType.UniqueIdentifier("rowguid"),
	RawType.DateTime("ModifiedDate")
});
 
rows.Select(x => new {
	CustomerID = (int)x["CustomerID"],
	FirstName = (string)x["FirstName"],
	MiddleName = (string)x["MiddleName"],
	LastName = (string)x["LastName"],
	CompanyName = (string)x["CompanyName"],
	EmailAddress = (string)x["EmailAddress"]
}).Dump();
Capture

And there we have it. 795 customers were just recovered from an otherwise unrecoverable state. Now it's just a matter of repeating this process for the other tables as well.

Summary

As I've just shown, even though all hope seems lost, there are still options. If you know what you're doing, a tool like OrcaMDF, or another homebrewn solution, might come in as an invaluable out, during a disaster. This is not, and should never be, a replacement for a good recovery strategy. That being said, not a week goes by without someone posting on a forum somewhere about a corrupt database without any backups.

In this case we went from fatal corruption to recovering 795 customers from the Customer table. Looking at the database, before it was corrupted, there was originally 847 customers in the table. Thus 52 customers were lost due to the corruption. If the pages really are hit by corruption, nothing will get that data back, unless you have a backup. However, if you're unlucky and end up with metadata corruption, and/or a database that won't come online, this may be a viable solution.

Should you come across a situation where OrcaMDF might come in handy, I'd love to hear about it - nothing better to hear than success stories! If you don't feel like going through this process yourself, feel free to contact me; I may be able to help.

Nov 05
2013

Sometimes you must first do evil, to do good. Such is the case when you want to hone your skills in corruption recovery of SQL Server databases.

To give me more material to test the new RawDatabase functionality, I’ve now added a Corruptor class to OrcaMDF. Corruptor does more or less what the name says – it corrupts database files on purpose.

The corruption itself is quite simple. Corruptor will choose a number of random pages and simply overwrite the page completely with all zeros. Depending on what pages are hit, this can be quite fatal.

I shouldn’t have to say this, but just in case… Please do not use this on anything valuable. It will fatally corrupt your data.

Examples

There are two overloads for the Corruptor.CorruptFile method, both of them return an IEnumerable of integers – a list of the page IDs that have been overwritten by zeros.

The following code will corrupt 5% of the pages in the AdventureWorks2008R2LT.mdf file, after which it will output each page ID that has been corrupted. You can specify the percentage of pages to corrupt by changing the second parameter.

var corruptedPageIDs = Corruptor.CorruptFile(@"C:\AdventureWorks2008R2LT.mdf", 0.05);
Console.WriteLine(string.Join(", ", corruptedPageIDs));
606, 516, 603, 521, 613, 621, 118, 47, 173, 579,
323, 217, 358, 515, 615, 271, 176, 596, 417, 379,
269, 409, 558, 103, 8, 636, 200, 361, 60, 486,
366, 99, 87

To make the corruption hit even harder, you can also use the second overload of the CorruptFile method, allowing you to specify the exact number of pages to corrupt, within a certain range of page IDs. The following code will corrupt exactly 10 pages within the first 50 pages (zero-based), thus hitting mostly metadata.

var corruptedPageIDs = Corruptor.CorruptFile(@"C:\AdventureWorks2008R2LT.mdf", 10, 0, 49);
Console.WriteLine(string.Join(", ", corruptedPageIDs));
16, 4, 0, 32, 15, 14, 30, 2, 49, 9

In the above case I was extraordinarily unlucky seeing as page 0 is the file header page, page 2 is the first GAM page, page 9 is the boot page and finally page 16 is the page that contains the allocation unit metadata. With corruption like this, you can be certain that DBCC CHECKDB will be giving up, leaving you with no other alternative than to restore from a backup.

Or… You could try to recover as much data as possible using OrcaMDF RawDatabase, but I’ll get back to that later :)

Nov 04
2013

When I initially started working on OrcaMDF I had just one goal, to gain a deeper knowledge of MDF file internals than I could through most books available.

As time progressed, so did OrcaMDF. While I had no initial plans of doing so, OrcaMDF has ended up being capable of parsing base tables, metadata and even dynamically recreating common DMVs. On top of this, I made a simple GUI, just to make OrcaMDF easier to use.

While that’s great, it comes at the price of extreme complexity. To be able to automatically parse table metadata like schemas, partitions, allocation units and more, not to mention abstracting away details like heaps and indexes, it takes a lot of code and it requires intimate knowledge of the database itself. Seeing as metadata changes between versions, OrcaMDF currently only supports SQL Server 2008 R2. While the data structures themselves are rather stable, there are minor differences in the way metadata is stored, the data exposed by DMVs and so forth. And on top of this, requiring all of the metadata to be perfect, for OrcaMDF to work, results in OrcaMDF being just as vulnerable to corruption as SQL Server is itself. Got a corrupt boot page? Neither SQL Server nor OrcaMDF will be able to parse the database.

Say Hello to RawDatabase

I tried to imagine the future of OrcaMDF and how to make it the most useful. I could march on make it support more and more of the same features that SQL Server does, eventually being able to parse 100% of an MDF file. But what would the value be? Sure, it would be a great learning opportunity, but the thing is, if you’ve got a working database, SQL Server does a pretty good job too. So what’s the alternative?

RawDatabase, in contrast to the Database class, doesn’t try to parse anything besides what you tell it to. There’s no automatic parsing of schemas. It doesn’t know about base tables. It doesn’t know about DMVs. It does however know about the SQL Server data structures and it gives you an interface for working with the MDF file directly. Letting RawDatabase parse nothing but the data structures means it’s significantly less vulnerable to corruption or bad data.

Examples

It’s still early in the development, but let me show some examples of what can be done using RawDatabase. While I’m running the code in LINQPad, as that makes it easy to show the results, the result are just standard .NET objects. All examples are run against the AdventureWorks 2008R2 LT (Light Weight) database.

Getting a Single Page

In the most basic example, we’ll parse just a single page.

// Get page 197 in file 1
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.GetPage(1, 197).Dump();
A

Parsing the Page Header

Now that we’ve got a page, how about we dump the header values?

// Get the header of page 197 in file 1
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.GetPage(1, 197).Header.Dump();
A

Parsing the Slot Array

Just as the header is available, you can also get the raw slot array entries.

// Get the slot array entries of page 197 in file 1
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.GetPage(1, 197).SlotArray.Dump();
A

Parsing Records

While getting the raw slot array entries can be useful, you’ll usually want to look at the records themselves. Fortunately, that’s easy to do too.

// Get all records on page 197 in file 1
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.GetPage(1, 197).Records.Dump();
A

Retrieving Data from Records

Once you’ve got the records, you could now access the FixedLengthData or the VariableLengthOffsetValues properties to get the raw fixed length and variable length column values. However, what you’ll typically want is to get the actually parsed values. To spare you the work, OrcaMDF can parse it for you, if you just provide it the schema.

// Read the record contents of the first record on page 197 of file 1
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
RawPrimaryRecord firstRecord = (RawPrimaryRecord)db.GetPage(1, 197).Records.First();
 
var values = RawColumnParser.Parse(firstRecord, new IRawType[] {
	RawType.Int("AddressID"),
	RawType.NVarchar("AddressLine1"),
	RawType.NVarchar("AddressLine2"),
	RawType.NVarchar("City"),
	RawType.NVarchar("StateProvince"),
	RawType.NVarchar("CountryRegion"),
	RawType.NVarchar("PostalCode"),
	RawType.UniqueIdentifier("rowguid"),
	RawType.DateTime("ModifiedDate")
});
 
values.Dump();
A

RawColumnParser.Parse will, given a schema, automatically convert the raw bytes into a Dictionary, the key being the column name from the schema and the value being the actual type of the column, e.g. int, short, Guid, string, etc. By letting you, the user, specify the schema, OrcaMDF can get rid of a slew of dependencies on metadata, thus ignoring any possible corruption in metadata. Given the availability of the Next & PreviousPageID properties of the header, it would be simple to iterate through all linked pages, parsing all records of each page – basically performing a scan on a given allocation unit.

Filtering Pages

Besides retrieving a specific page, RawDatabase also has a Pages property that enumerates over all pages in a database. Using this you could, for example, get a list of all IAM pages in the database.

// Get a list of all IAM pages in the database
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.Pages
	.Where(x => x.Header.Type == PageType.IAM)
	.Dump();
A

And since this is powered by LINQ, it’s easy to project just the properties you want. For example, you could get all index pages and their slot counts like this:

// Get all index pages and their slot counts
var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.Pages
	.Where(x => x.Header.Type == PageType.Index)
	.Select(x => new {
		x.PageID,
		x.Header.SlotCnt
	}).Dump();
A

Or let’s say you wanted to get all data pages with at least one record and more than 7000 bytes of free space – with the page id, free count, record count and average record size as the output:

var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
db.Pages
	.Where(x => x.Header.FreeCnt > 7000)
	.Where(x => x.Header.SlotCnt >= 1)
	.Where(x => x.Header.Type == PageType.Data)
	.Select(x => new {
	    x.PageID,
		x.Header.FreeCnt,
		RecordCount = x.Records.Count(),
		RecordSize = (8096 - x.Header.FreeCnt) / x.Records.Count()
	}).Dump();
A

And as a final example, imagine you’ve got just an MDF file but you seem to have forgotten what objects are stored inside of it. Fret not, we’ll just get the data from the sysschobjs base table! Sysschobjs is the base table that stores all object data, and fortunately it has a static object ID of 34. Using this, we can filter down to all of the data pages for object 34, get all the records and then parse just the two first columns of the schema (you may specify a partial schema, as long as you only omit columns at the end), ending up in us dumping just the names (we could of course have gotten the full schema, if we wanted to).

var db = new RawDatabase(@"C:\AWLT2008R2.mdf");
 
var records = db.Pages
	.Where(x => x.Header.ObjectID == 34 && x.Header.Type == PageType.Data)
	.SelectMany(x => x.Records);
 
var rows = records.Select(x => RawColumnParser.Parse((RawPrimaryRecord)x, new IRawType[] {
	RawType.Int("id"),
	RawType.NVarchar("name")
}));
 
rows.Select(x => x["name"]).Dump();
A

Compatibility

Seeing as RawDatabase doesn’t rely on metadata, it’s much easier to support multiple SQL Server versions. Thus, I’m happy to say that RawDatabase fully supports SQL Server 2005, 2008, 2008R2 and 2012. It probably supports 2014 too, I just haven’t tested that. Speaking of testing, all unit tests are automatically run against AdventureWorksLT for both 2005, 2008, 2008R2 and 2012 during testing. Right now there are tests demonstrating that OrcaMDF RawDatabase is able to parse the first record of each and every table in the AdventureWorks LT databases.

Corruption

One of the really interesting use cases for RawDatabase is in the case of corrupted databases. You could filter pages on the object id you’re searching for and then brute-force parse each of them, retrieving whatever data is readable. If metadata is corrupted, you could ignore it, provide the schema manually and the just follow the linked lists of pages, or parse the IAM pages to read heaps. During the next couple of weeks I’ll be blogging more on OrcaMDF RawDatabase to show various use case examples, including ones on corruption.

Source & Feedback

I’m really excited about the new RawDatabase addition to OrcaMDF and I hope I’m not the only one who can see the potential. If you try it out, have any ideas, suggestions or other kinds of feedback, I’d love to hear it.

If you want to try it out, head on over to the OrcaMDF project on GitHub. Once it’s just a bit more polished, I’ll make it available on NuGet as well. Just like the rest of OrcaMDF, the code is licensed under GPL v3.

Oct 28
2013

I love presenting, especially so when it’s possible for me to do so alongside Powerpoints presenters view. Unfortunately I’m an even bigger fan of ZoomIt and I use it extensively when presenting. Why is that an issue? To use ZoomIt effectively, not just in demos but when showing slides as well, I need to duplicate my screen rather than extending it. Duplicating the screen means presenters view is not an option :(

Introducing PowerPad

Seeing as I’ve already got my iPad next to me when presenting it seems obvious to use that for the presenters view. However, even though I’ve scoured the app store for solutions, I have yet to find something that doesn’t require me to install invasive clients on my computer or suffice with a fixed & lagging UI on the iPad. Even worse, most require me to pay up front, meaning I can’t perform a meaningful trial.

And so I decided to do something about it. PowerPad is a simple console application that runs on your computer, detects when you run a presentation and automatically provides a “presenters view” served over HTTP. The overall goal for PowerPad is to provide a Powerpoint presenters view for tablets & phones.

presentation_started

As soon as you’re running PowerPad, and a presentation, you’ll now be able to access the host IP through any device with a browser. I personally use my iPad:

screen_notes

And in a pinch I might even use my phone:

screen_mobile

Getting Started

PowerPad is open source and completely free to use, licensed under the MIT license. It currently supports Powerpoint 2013 and only requires you to have the .NET 2.0 Framework installed. As long as your devices are on the same network, you can hook up any number of secondary monitors to your presentation – even your attendees, should you want to.

For more screenshots as well as the code & downloads, please check out the PowerPad page on Github.

Oct 23
2013

I’m slightly late to announce this, but better late than never!

Just a few weeks ago, the book Tribal SQL went for sale! I authored a chapter on “Storage Internals 101″ and alongside 14 other first-time authors, this is our first book to have published!

tribalSQLcover
Tribal SQL: New voices in SQL Server

15 first-time authors answer the question: What makes you passionate about working with SQL Server?

MidnightDBA and Red Gate partnered to produce a book filled with community, Tribal, knowledge on SQL Server. The resulting book is a series of chapters on lessons learned, perhaps the hard way, which you won’t find in traditional training or technical guidance material.

As a truly community-driven book, the authors are all generously donating 100% of their royalties to the charity Computers 4 Africa.

A DBA’s core responsibilities are constant. A DBA must have the hard skills necessary to maintain and enforce security mechanisms on the data, prepare effectively for disaster recovery, ensure the performance and availability of all the databases in their care.

Side by side with these, our authors have also recognized the importance of communication skills to the business and their careers. We have chapters on the importance to a DBA of communicating clearly with their co-workers and business leaders, presenting data as useful information that the business can use to make decisions, and sound project management skills.

The resulting book, Tribal SQL, is a reflection of how a DBA’s core and long-standing responsibilities and what it means to be a DBA in today’s businesses.

If you want to get a sneak peek of my chapter, it has been posted on Simple-Talk as an extract of the complete book.

Oct 08
2013

One of the main culprits when it comes to ASP.NET concurrency is caused by the fact that default sesion state has been implemented using a pessimistic locking pattern. Basically, any standard handler, whether that be an ASPX page, a generic handler or an ASMX web service, goes through the following steps:

  • Retrieve & exclusively lock session
  • Execute request handler
  • Save & unlock updated session (whether updates have been made or not)

What this means is that, for a given session, only one request can execute concurrently. Any other requests, from that same session, will block, waiting for the session to be released. For the remainder of this post I’ll concentrate on generic HttpHandlers, but this problem & solution is common to for ASPX and ASMX pages as well.

Disabling Session State

If your handler doesn’t require session state, all you have to do is to not implement the IRequiresSessionState interface, given that HttpHandlers by default do not have access to session state:

public class MyHandler : IHttpHandler
{
	public void ProcessRequest(HttpContext context)
	{
		// Perform some task
	}
 
	public bool IsReusable { get { return false; } }
}

By not enabling session state, no session will be locked and you can execute as many concurrent requsts as your server can handle.

Enabling Session State

If you do need session state, simply implement the IRequiresSessionState interface, like so:

public class MyHandler : IHttpHandler, IRequiresSessionState
{
	public void ProcessRequest(HttpContext context)
	{
		// Perform some task
	}
 
	public bool IsReusable { get { return false; } }
}

The IRequiresSessionState interface carries no functionality at all, it’s simply a marker interface that tells the ASP.NET request pipeline to acquire session state for the given request. By implementing this interface you now have read+write access to the current session.

Read-Only Session State

If all you need is to read session state, while not having to be able to write it, you should implement the IReadOnlySessionState interface instead, like so:

public class MyHandler : IHttpHandler, IReadOnlySessionState
{
	public void ProcessRequest(HttpContext context)
	{
		// Perform some task
	}
 
	public bool IsReusable { get { return false; } }
}

Implementing this interface changes the steps performed by the page slightly:

  • Retrieve session, without locking
  • Execute request handler
  • Save & unlock updated session (whether updates have been made or not)

While session is still read as usual, it’s just not persisted back after the request is done. This means you can actually update the session, without causing any exceptions. However, as the session is never persisted, your changes won’t be saved after the request is done. For read-only use this also saves the superfluous save operation which can be costly if you’re using out-of-process session state like State or SQL Server.

Switching Between Read+Write and Read-Only Session State Programmatically

While this is great, we sometimes need something in between. Consider the following scenario:<7p>

  • You’ve got a single handler that’s heavily requested.
  • On the first request you need to perform some expensive lookup to load some data that will be used in all further requests, but is session specific, and will thus be stored in session state.
  • If you implement IRequiresSessionState, you can easily detect the first request (Session["MyData"] == null), load the data, store it in session and then reuse it in all subsequent requests. However, this ensures only one request may execute at a time, due to the session being exclusively locked while the handler executes.
  • If you instead implement IReadOnlySessionState, you can execute as many handlers concurrently as you please, but you’ll have to do that expensive data loading on each request, seeing as you can’t store it in session.

Imagine if you could dynamically decide whether to implement the full read+write enabled IRequiresSessionState or just the read enabled IReadOnlySession state. That way you could implement IRequiresSessionState for the first request and just implement IReadOnlySessionState for all of the subsequent requests, once a session has been established.

And guess what, from .NET 4.0 onwards, that’s possible!

Enter HttpContext.SetSessionStateBehavior

Looking at the ASP.NET request pipeline, session state is loaded in the “Acquire state” event. At any point, before this event, we can set the session behavior programmatically by calling HttpContext.SetSessionStateBehavior. Setting the session programmatically through HttpContext.SetSessionStateBehavior will override any interfaces implemented by the handler itself.

Here’s a full example of an HttpModule that runs on each request. In the PostMapRequestHandler event (which fires just before the AcquireState event), we inspect the HttpHandler assigned to the request. If it implements the IPreferReadOnlySessionState interface (a custom marker interface), the SessionStateBehavior is set to ReadOnly, provided there already is an active session (which the presence of an ASP.NET_SessionId cookie indicates). If there is no session cookie present, or if the handler doesn’t implement IPreferReadOnlySessionState, then it’s left up to the handler default – that is, the implemented interface, to decide.

public class RequestHandler : IHttpModule
{
	public void Init(HttpApplication context)
	{
		context.PostMapRequestHandler += context_PostMapRequestHandler;
	}
 
	void context_PostMapRequestHandler(object sender, EventArgs e)
	{
		var context = HttpContext.Current;
 
		if (context.Handler is IPreferReadOnlySessionState)
		{
			if (context.Request.Headers["Cookie"] != null && context.Request.Headers["Cookie"].Contains("ASP.NET_SessionId="))
				context.SetSessionStateBehavior(SessionStateBehavior.ReadOnly);
		}
	}
}

Now all we need to do is to also implement the IPreferReadOnlySessionState interface in the handlers that can do with read-only sesion state, provided a session is already present:

public interface IPreferReadOnlySessionState
{ }
public class MyHandler : IHttpHandler, IRequiresSessionState, IPreferReadOnlySessionState
{
	public void ProcessRequest(HttpContext context)
	{
		// Perform some task
	}
 
	public bool IsReusable { get { return false; } }
}

And just like that, the first request has read+write access to the session state, while all subsequent requests only have read access, greatly increasing the concurrency of the handler.

Sep 23
2013

Mailgun has a very neat feature that enables you to basically convert incoming emails to a POST request to a URL of your choice, also known as a webhook. Using this, you can easily have your application respond to email events. However, as this URL/service needs to be publically available, verifying Mailgun webhooks is very important, ensuring requests actually come from Mailgun, and not someone impersonating Mailgun.

The code required for verifying Mailgun forwards is very simple and doesn’t require much explanation:

/// <summary>
/// Verifies that the signature matches the timestamp & token.
/// </summary>
/// <returns>True if the signature is valid, otherwise false.</returns>
public static bool VerifySignature(string key, int timestamp, string token, string signature)
{
	var encoding = Encoding.ASCII;
	var hmacSha256 = new HMACSHA256(encoding.GetBytes(key));
	var cleartext = encoding.GetBytes(timestamp + token);
	var hash = hmacSha256.ComputeHash(cleartext);
	var computedSignature = BitConverter.ToString(hash).Replace("-", "").ToLower();
 
	return computedSignature == signature;
}

Use sample:

// All these values are provided by the Mailgun request
var key = "key-x3ifab7xngqxep7923iuab251q5vhox0";
var timestamp = 1568491354;
var token = "asdoij2893dm98m2x0a9sdkf09k423cdm";
var signature = "AF038C73E912A830FFC830239ABFF";
 
// Verify if request is valid
bool isValid = VerifySignature(key, timestamp, token, signature);

As the manual says you simply need to calculate a SHA256 HMAC of the concatenated timestamp and token values, after which you can verify that it matches the Mailgun provided signature. The key is the private API key, retrievable from the Mailgun control panel.

Jun 04
2013

Unfortunately, once in a while, computers fail. If you’re running Windows you’ve probably witnessed the dreaded Blue Screen of Death, commonly referred to as a BSOD. Once the BSOD occurs, some machines will immediately restart, before you’ve got a chance to actually see what happened. Other times users will just report that the BSOD happened, without noting anything down about what the message actually said. In this post I’ll show you how analyzing BSOD minidump files using Windbg will enable you to find the cause of the BSOD after the fact.

Enabling Dump Files

By default, never Windows installs will automatically create minidump files once a BSOD occurs. Once restarted, you should be able to see a .dmp file here:

C:\Windows\Minidump

If you don’t see any .dmp files there, or if the directory doesn’t exist, you may have to tell Windows to create minidump files when the BSOD occurs. To do so, press the Win+Break keys to open up the System control panel. Now click Advanced system settings in the left menu. Once there, go to the Advanced tab and click the Settings… button under the Startup and Recovery section. Now make sure the Write debugging information setting is set to anything but “none”:

Capture

Analyzing BSOD Minidump Files Using Windbg

Once a dump file has been created, you can analyze it using Windbg. Start by opening Windbg and pressing the Ctrl+D keys. Now select the .dmp file you want to analyze and click Open. This should yield something like this:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
 
 
Loading Dump File [C:\Windows\Minidump\040813-15974-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
 
Symbol search path is: symsrv*symsrv.dll*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18044.amd64fre.win7sp1_gdr.130104-1431
Machine Name:
Kernel base = 0xfffff800`0300c000 PsLoadedModuleList = 0xfffff800`03250670
Debug session time: Mon Apr  8 22:17:47.016 2013 (UTC + 2:00)
System Uptime: 0 days 1:36:19.860
Loading Kernel Symbols
...............................................................
................................................................
........................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
Use !analyze -v to get detailed debugging information.
 
BugCheck FE, {4, fffffa803c3c89e0, fffffa803102e230, fffffa803e765010}
 
Probably caused by : FiioE17.sys ( FiioE17+1d21 )
 
Followup: MachineOwner

Already this tells us a couple of things – your OS details, when exactly the problem occurred as well as what module probably caused the issue (FiioE17.sys in this case). Also, it tells you how to proceed:

Use !analyze -v to get detailed debugging information.

As suggested, let’s try and run the !analyze -v command:

11: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
 
BUGCODE_USB_DRIVER (fe)
USB Driver bugcheck, first parameter is USB bugcheck code.
Arguments:
Arg1: 0000000000000004, IRP_URB_DOUBLE_SUBMIT The caller has submitted an irp
	that is already pending in the USB bus driver.
Arg2: fffffa803c3c89e0, Address of IRP
Arg3: fffffa803102e230, Address of URB
Arg4: fffffa803e765010
 
Debugging Details:
------------------
 
CUSTOMER_CRASH_COUNT:  1
 
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
 
BUGCHECK_STR:  0xFE
 
PROCESS_NAME:  audiodg.exe
 
CURRENT_IRQL:  2
 
LAST_CONTROL_TRANSFER:  from fffff88008326f4b to fffff80003081c40
 
STACK_TEXT:  
fffff880`0e482fd8 fffff880`08326f4b : 00000000`000000fe 00000000`00000004 fffffa80`3c3c89e0 fffffa80`3102e230 : nt!KeBugCheckEx
fffff880`0e482fe0 fffff880`0833244a : fffffa80`3ae97002 fffffa80`3b8caad0 00000000`00000000 fffffa80`3ae97050 : USBPORT!USBPORT_Core_DetectActiveUrb+0x127
fffff880`0e483030 fffff880`0833ae74 : fffffa80`3c3c89e0 fffffa80`3af7000a fffffa80`3c3c89e0 fffffa80`3102e230 : USBPORT!USBPORT_ProcessURB+0xad6
fffff880`0e4830e0 fffff880`08314af4 : 00000000`00000000 fffffa80`3af7b050 fffffa80`3e5d1720 fffffa80`3c3c89e0 : USBPORT!USBPORT_PdoInternalDeviceControlIrp+0x138
fffff880`0e483120 fffff880`00fa97a7 : fffffa80`3c3c89e0 fffffa80`31192040 fffffa80`3c3c89e0 fffffa80`3c3c89e0 : USBPORT!USBPORT_Dispatch+0x1dc
fffff880`0e483160 fffff880`00fb1789 : fffff880`00fcfb50 fffffa80`3d944ed1 fffffa80`3c3c8d38 fffffa80`3c3c8d38 : ACPI!ACPIDispatchForwardIrp+0x37
fffff880`0e483190 fffff880`00fa9a3f : fffff880`00fcfb50 fffffa80`316a7a90 fffffa80`3c3c89e0 fffffa80`3ab6c050 : ACPI!ACPIIrpDispatchDeviceControl+0x75
fffff880`0e4831c0 fffff880`088ca566 : 00000000`00000000 00000000`00000004 fffffa80`3ab6c050 fffffa80`3c2bd440 : ACPI!ACPIDispatchIrp+0x12b
fffff880`0e483240 fffff880`088fad8f : 00000000`00000000 00000000`00000000 fffffa80`3c2bd440 00000000`00000000 : usbhub!UsbhFdoUrbPdoFilter+0xde
fffff880`0e483270 fffff880`088c8fb7 : fffffa80`3c3c89e0 fffffa80`3a976ce0 fffffa80`3c3c89e0 fffffa80`3c3c89e0 : usbhub!UsbhPdoInternalDeviceControl+0x373
fffff880`0e4832c0 fffff880`00fa97a7 : fffffa80`3c3c89e0 fffff800`031b630d fffffa80`3b7be100 00000000`00000801 : usbhub!UsbhGenDispatch+0x57
fffff880`0e4832f0 fffff880`00fb1789 : fffff880`00fcfb50 00000000`00000001 fffffa80`3c393b58 fffffa80`3c3c8d38 : ACPI!ACPIDispatchForwardIrp+0x37
fffff880`0e483320 fffff880`00fa9a3f : fffff880`00fcfb50 fffffa80`316a8a90 fffffa80`3c3c89e0 fffffa80`3c393b58 : ACPI!ACPIIrpDispatchDeviceControl+0x75
fffff880`0e483350 fffff880`08c9bec4 : 00000000`00000000 fffffa80`3c326938 fffffa80`3c393b58 00000000`00000000 : ACPI!ACPIDispatchIrp+0x12b
fffff880`0e4833d0 fffff880`08c98812 : fffffa80`3c393b58 fffffa80`3c3c89e0 fffffa80`00000324 fffffa80`3c3c89e0 : usbccgp!UsbcForwardIrp+0x30
fffff880`0e483400 fffff880`08c98aba : fffffa80`3c326838 00000000`00220003 fffffa80`3c3c89e0 fffffa80`3c393b58 : usbccgp!DispatchPdoUrb+0xfa
fffff880`0e483440 fffff880`08c9672e : 00000000`0000000f fffffa80`3c393b50 fffffa80`3c393b58 fffffa80`3c3c89e0 : usbccgp!DispatchPdoInternalDeviceControl+0x17a
fffff880`0e483470 fffff880`08cb3d21 : fffffa80`3c393a00 fffffa80`3c3c8901 fffffa80`3c3c8900 00000000`00000000 : usbccgp!USBC_Dispatch+0x2de
fffff880`0e4834f0 fffffa80`3c393a00 : fffffa80`3c3c8901 fffffa80`3c3c8900 00000000`00000000 fffffa80`3c373010 : FiioE17+0x1d21
fffff880`0e4834f8 fffffa80`3c3c8901 : fffffa80`3c3c8900 00000000`00000000 fffffa80`3c373010 00000000`00000000 : 0xfffffa80`3c393a00
fffff880`0e483500 fffffa80`3c3c8900 : 00000000`00000000 fffffa80`3c373010 00000000`00000000 fffffa80`3c3b7f30 : 0xfffffa80`3c3c8901
fffff880`0e483508 00000000`00000000 : fffffa80`3c373010 00000000`00000000 fffffa80`3c3b7f30 fffff880`08cb47fd : 0xfffffa80`3c3c8900
 
 
STACK_COMMAND:  kb
 
FOLLOWUP_IP: 
FiioE17+1d21
fffff880`08cb3d21 ??              ???
 
SYMBOL_STACK_INDEX:  12
 
SYMBOL_NAME:  FiioE17+1d21
 
FOLLOWUP_NAME:  MachineOwner
 
MODULE_NAME: FiioE17
 
IMAGE_NAME:  FiioE17.sys
 
DEBUG_FLR_IMAGE_TIMESTAMP:  50b30686
 
FAILURE_BUCKET_ID:  X64_0xFE_FiioE17+1d21
 
BUCKET_ID:  X64_0xFE_FiioE17+1d21
 
Followup: MachineOwner

This tells us a number of interesting things:

  • The BSOD error was: BUGCODE_USB_DRIVER
  • This is the error caused by the driver: IRP_URB_DOUBLE_SUBMIT The caller has submitted an irp that is already pending in the USB bus driver.
  • The process that invoked the error: audiodg.exe
  • The stack trace of the active thread on which the error occurred. Note that Windbg can’t find the right symbols as this is a proprietary driver with no public symbols. Even so, to the developer of said driver, the above details will help immensely.
  • The driver name: FiioE17.sys

With the above options, you’ve got a lot of details that can be sent to the developer, hopefully enabling him/her/them to fix the issue. For now, I’ll have to unplug my Fiio E17 USB DAC :(

May 28
2013

I’m delighted to announce that I’ll be speaking at this years SQL PASS Summit in Charlotte, North Carolina. Having submitted several times before, unsuccessfully, I’m really happy to have made the cut this year. Looking at the lineup of speakers, I take great pride in being given the opportunity.

My Sessions

That’s right, not just one session, but two! And as if that wasn’t enough, the two selected sessions are my absolute favorite ones to perform! I’ve presented both several times before and thanks to great feedback from the audiences I’ve slowly fine tuned the format and content.

Top Tricks and Best Practices for .NET SQL Server Developers

This is a session chock-full of easy-to-use tips, tricks and gotchas that can be implemented immediately. If you’re either a .NET developer yourself, or if you have .NET developers on your team, using SQL Server, this session is sure to be an eye opener with valuable lessons.

Being the acting DBA while doing development and managing a team of .NET developers, I’ve learned a trick or two through the years. For this session, I’ve gathered my list of top tricks any .NET developer should know and use when dealing with SQL Server. We’ll cover how to use TransactionScopes without locking up the database, avoiding MSDTC escalation, using internal batching functions in the BCL through reflection, avoiding unnecessary round trips, and much more. These are tips, tricks, and best practices that I ensure all my developers are taught before they have a chance of committing code to our production systems.

Understanding Data Files at the Byte Level

The best part about this session, for me, is watching heads explode only 15 minutes in when I make a live demonstration of how to reverse engineer SQL Server, to persuade it into describing its own data file format. In just 75 minutes I will give you not only a thorough tour of the MDF file format, but also a plethora of techniques on how to analyze your own databases internal storage as well. Using these techniques you’ll be well armed when it comes to schema discussions, column type choice and for those rare events where you need to dive just a bit below the surface to discover what’s really happening.

This session won’t explain when to use a heap instead of an index, but you will learn how they work – and differ – behind the scenes. Demonstrations will show how data files are organized on the disk and how that organization allows SQL Server to effectively query the data. Knowing how data files are organized will in turn help immensely when it comes to optimizing databases for both performance and storage efficiency.