BSOD 0x83: A BSOD So Useless It Shouldn't Even Be There

[winnt32]

I was looking through Vista SP2's NTKRNLPA for a mod i'm working on. NTKRNLPA, NTOSKRNL, etc has a list of every single BSOD (like kernel32.mui.dll, which contains every single system error code) located in a message table. I found this little guy sitting in the list of stop codes:

Code: Select all

0x83,  		"OFS_FILE_SYSTEM\r\n\x00"

OFS (or Cairo Object File System) was the relational database filesystem planned for Cairo, a cancelled Microsoft project from the early 1990s with very ambitious goals (not unlike Longhorn, so similar in fact that some in Microsoft were calling pre-reset Longhorn "Cairo.NET"). We have one leaked build (build 1175), another with a disc scan (build 297), and a post-RTM NT 3.5 or early NT 3.51 build with some Cairo components on the disc (build 854).

It has been pretty much determined that Cairo was an #ifdef affair, and you could build either standard NT or NT Cairo variations of a build. So why is this error message, presumably to indicate to a user a problem with their OFS file system, still there in Vista, years later?. (I also checked another, far more recent NTOSKRNL, Windows 10 build 18317 (just happened to have the ntoskrnl lying around) and the error message is still there.)

Since there is no OFS, this error can never be triggered.

[Kokutetsu]

Pretty funny how such a legacy component that never ended up coming to fruition still has its mark in much newer versions of Windows.

Microsoft had planned for an object based filesystem to be implemented with Windows Vista in the form of Windows Future Storage, but that also ended up getting shelved. Since you're working on a Vista mod, perhaps create something that can cause this BSOD to come up? Hahahaha

[jimmsta]

Microsoft isn't known for cleaning up their includes - lots of little bits of info can be gleaned from their include files - they likely ended up stripping the includes when they built Minwin for Windows 7's kernel. They may have let this pass through as an oversight. It should be noted that by the time Cairo build 1175 came around, the implementation of OFS was no longer "Object File System", but "OLE File System", which in turn became the basis for the Active Directory data store. OFS didn't die exactly - it just evolved into an on-disk data file structure.

[winnt32]

@Kokutestsu: WinFS was an extension of NTFS, not a new filesystem.
Microsoft skips over this in their documentation, as well as BSODs 0x84, 0x86-0x8A, 0x8C, 0x8D, 0x91, 0x95, 0xA8-AA, 0xB2, 0xB3, 0xB5-B7, 0xC0, 0xC3, 0xE5, 0xEE, 0xFB, 0x107, 0x10B, 0x110, 0x118, 0x13E, 0x13F, 0x146, 0x148, 0x172, 0x176, 0x177, 0x17A, 0x17F-0x186, 0x18A, 0x18F, 0x194, 0x19E, 0x19F, 0x1A1, 0x1A2, 0x1A9-0x1AF, 0x1B1-0x1C3, 0x1DA, and probably some others.

In vista, the last regularly numbered BSOD is 0x12C, so I'm only going to look at 0x84-0x12C:
At least according to the message table in NTOSKRNL (there may be more hidden although there likely is not)
- 0x84 is "RECOM_DRIVER". Unknown what this means, although it is driver related.
- The message listed for 0x86 is "Audit attempt has failed.", which most likely is a security violation.
- 0x87 through 0x8A, 0x8C, and 0x8D do not exist in Vista.
- 0x91 is "WIN32K_INIT_OR_RIT_FAILURE", - Win32k Initalisation or Reinitalisation failure. Most likely means an error while Win32k.sys was initalizing. Not sure why this one is undocumented.
- 0x95 is "PNP_INTERNAL_ERROR" - An internal error with Plug and Play.
- The 0xA8, 0xA9, and 0xAA message IDs are used for safe mode. Interestingly, they describe themselves as "Minimal Services"
- 0xB2 and 0xB3 do not exist.
- Message IDs 0xB5 through 0xB7 are used for boot logging.
- 0xC0 is "An attempt to access PCI configuration space failed." in the message table. Self-explanatory. Why is it undocumented? Who knows.
- Message ID 0xC3 is used for replacing signatured files with their originals.
- 0xE5 is "POWER_FAILURE_SIMULATE". Used for simulating power failures at Microsoft, I assume.
- The description for 0xEE is "The kernel attempted to ready a thread that was in an incorrect state such as terminated." I assume this would require a bug in the kernel if it was trying to ready a thread that had already been discarded?
- The description for 0xFB is "A machine check exception occurred just after processing a previous machine check, but\r\nbefore an exit from the machine check code could be completed." This has such a narrow use that I assume Microsoft didn't think it worth documenting.
- The description of 0x107 is "A thread is terminating or attempting a win32 callout while running on an expanded stack.". Self-explanatory.
- 0x10B is "DFSC_FILE_SYSTEM". I have no idea what DFSC is. DFS_FILE_SYSTEM is error 0x82, for Microsoft Distributed File System.
http://download.microsoft.com/download/ ... FSC%5D.pdf This link doesn't exist, but it calls itself MS-DSFC.
- 0x118 is "The kernel has detected an inconsistency in hypervisor enlightened operation." For a start, "enlightened". I assume this is what would happen if there was some securtiy problem with Hyper-V.

[Edness]

- 0x10B is "DFSC_FILE_SYSTEM". I have no idea what DFSC is. DFS_FILE_SYSTEM is error 0x82, for Microsoft Distributed File System.
http://download.microsoft.com/download/ ... FSC%5D.pdf This link doesn't exist, but it calls itself MS-DSFC.

DFSC stands for DFS Client if I'm not mistaken and it's an error that would probably be triggered by a client-side driver error. You can find either DFSC.SYS or DFSCLI.SYS inside the System32 folder too.
As for the non-working link, a quick google search of the filename [MS-DFSC].pdf will lead you to a working link, here's the top result I found to be functional at the time of writing this