2.1.3 causing POOL_CORRUPTION_IN_FILE_AREA crash - Win8.1

[comco]

Hey guys,
Providing as a head's up - haven't tried to replicate this yet. More for the dev's info than anything else. Have a newly built system (Intel quad core with ASUS Formula VI Maximus motherboard) that suffered a BSOD today. Looking at the crash dump, it appears that VLC might have been the culprit. I was watching a largeish (2.2GB) MKV (H264 - MPEG-4 AVC) video, streamed off a Samba share sitting on a QNAP NAS.

Just FYI - the system was working hard at the time as I was playing a resource intensive game on one screen while watching the MKV on the other, so there would have been a lot of memory paging going on, I'd imagine.

VLC crashed during playback and while it was attempting to close, the entire OS crashed with a BSOD stating "POOL_CORRUPTION_IN_FILE_AREA".

More info from the crash report -

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

POOL_CORRUPTION_IN_FILE_AREA (de)
A driver corrupted pool memory used for holding pages destined for disk.
This was discovered by the memory manager when dereferencing the file.
Arguments:
Arg1: 0000000000000002
Arg2: ffffc0007784d110
Arg3: ffffc0007784d011
Arg4: 000000006fb3f8c0

Debugging Details:
------------------


DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0xDE

PROCESS_NAME: vlc.exe

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80244b88685 to fffff80244b70fa0

STACK_TEXT:
ffffd000`24ea5e18 fffff802`44b88685 : 00000000`000000de 00000000`00000002 ffffc000`7784d110 ffffc000`7784d011 : nt!KeBugCheckEx
ffffd000`24ea5e20 fffff802`44a4e21c : ffffe001`58c08301 ffffe001`58c08300 ffffe001`58c083d0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x71d5
ffffd000`24ea5ee0 fffff801`8933ecbb : ffffe001`59164018 ffffd000`210ea2a0 00000000`00000000 00000000`00000000 : nt!CcPurgeCacheSection+0xc8
ffffd000`24ea5f50 fffff802`44b748f7 : ffffd000`24ea5fd0 ffffe001`54fe7e10 ffffe001`59182880 ffffd000`210ea150 : rdbss!RxpPurgeFcbInSystemCacheCallout+0x53
ffffd000`24ea5f80 fffff802`44b748bd : 00000000`00000000 00000000`00000000 00000000`00000002 fffff802`44af7388 : nt!KxSwitchKernelStackCallout+0x27
ffffd000`210ea150 fffff802`44af7388 : 00000000`00000006 00000000`00000000 00000000`00000006 00000000`00000000 : nt!KiSwitchKernelStackContinue
ffffd000`210ea170 fffff801`89379821 : fffff801`8933ec68 ffffd000`210ea2a0 ffffc000`74147500 ffffc000`74147520 : nt!KeExpandKernelStackAndCalloutInternal+0x218
ffffd000`210ea260 fffff801`89372ff2 : ffffe001`55ce23c0 ffffe001`54fe7e10 ffffc000`74147520 ffffc000`74147520 : rdbss!RxPurgeFcbInSystemCache+0xb9
ffffd000`210ea300 fffff801`89339d9e : ffffe001`522da4d0 ffffe001`54fe7e10 ffffe001`54fe7e00 fffff801`00000000 : rdbss!RxCommonCleanup+0x522
ffffd000`210ea430 fffff801`8936a7df : ffffe001`55ce23c0 ffffe001`52938d40 00000000`00000000 ffffe001`54fe7e10 : rdbss!RxFsdCommonDispatch+0x56e
ffffd000`210ea5a0 fffff801`8b2431b3 : 00000000`00000000 ffffe001`54fe7e01 ffffe001`54fe7e10 ffffe001`59732970 : rdbss!RxFsdDispatch+0xcf
ffffd000`210ea610 fffff801`88a50682 : ffffe001`597328d0 ffffe001`54fe7e10 ffffc000`61b7d780 00000000`c0000016 : mrxsmb!MRxSmbFsdDispatch+0x83
ffffd000`210ea650 fffff801`88a4f954 : ffffc000`61b7d780 ffffe001`55ce23c0 00000000`00000000 fffff801`880be7bc : mup!MupiCallUncProvider+0xc2
ffffd000`210ea6c0 fffff801`880bdcf8 : ffffd000`210ea760 ffffe001`597328d0 ffffe001`54fe7e10 ffffe001`54fe7fb8 : mup!MupCleanup+0x1d4
ffffd000`210ea720 fffff801`880bc0b6 : ffffe001`5293a580 00000000`00000000 ffffe001`54fe7e10 00000000`00000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x258
ffffd000`210ea7c0 fffff802`44e0fb32 : ffffe001`54fe7e10 ffffe001`55713540 00000000`00000000 ffffe001`5515b7f0 : FLTMGR!FltpDispatch+0xb6
ffffd000`210ea820 fffff802`44e2674a : ffffe001`55ce2390 ffffe001`5132a9a0 ffffe001`55ce23a0 ffffe001`55ce2300 : nt!IopCloseFile+0x152
ffffd000`210ea8b0 fffff802`44e26543 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff802`00000001 : nt!ObpDecrementHandleCount+0x1b6
ffffd000`210ea950 fffff802`44e2617e : 00000000`00000000 00000000`00001c70 00000000`00000000 00000000`00000000 : nt!ObCloseHandleTableEntry+0x313
ffffd000`210eaa20 fffff802`44e3a6c5 : 00000000`00040001 ffffd000`210eab80 ffffe001`55713540 ffffd000`210eab80 : nt!ExSweepHandleTable+0xba
ffffd000`210eaa80 fffff802`44e3a3b0 : 00000000`00040000 00000000`00000000 ffffd000`210eab80 00000000`00000000 : nt!ObKillProcess+0x31
ffffd000`210eaab0 fffff802`44dfc3ce : ffffe001`55713540 ffffc000`75f7d9b0 ffffd000`210eab80 00000000`00000000 : nt!PspRundownSingleProcess+0xa4
ffffd000`210eab40 fffff802`44ec2874 : 00000000`c0000005 ffffe001`59182880 ffffd000`210eae40 ffffe001`59182928 : nt!PspExitThread+0x52e
ffffd000`210eac50 fffff802`44a7559d : 00000000`0904f128 00000000`0000002b ffffd000`210eb000 ffffd000`210e5000 : nt!KiSchedulerApcTerminate+0x18
ffffd000`210eac80 fffff802`44b75ec0 : 00000000`0749e840 ffffd000`210ead00 fffff802`44a61368 00000000`00000000 : nt!KiDeliverApc+0x2ed
ffffd000`210ead00 fffff802`44b7c85a : ffffe001`59182880 00000000`76edaf20 00000000`00000020 ffffd000`2108db00 : nt!KiInitiateUserApc+0x70
ffffd000`210eae40 00007ff8`83c1c980 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9f
00000000`0749e7c0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`83c1c980


STACK_COMMAND: kb

FOLLOWUP_IP:
rdbss!RxpPurgeFcbInSystemCacheCallout+53
fffff801`8933ecbb 8b0da3fc0100 mov ecx,dword ptr [rdbss!Microsoft_Windows_Remotefs_RdbssEnableBits (fffff801`8935e964)]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: rdbss!RxpPurgeFcbInSystemCacheCallout+53

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: rdbss

IMAGE_NAME: rdbss.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 52affb72

BUCKET_ID_FUNC_OFFSET: 53

FAILURE_BUCKET_ID: 0xDE_rdbss!RxpPurgeFcbInSystemCacheCallout

BUCKET_ID: 0xDE_rdbss!RxpPurgeFcbInSystemCacheCallout

Followup: MachineOwner

[FlyinHawaiian]

This might not be VLC at all from the Crash Report:

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

AFAIK VLC Doesn't do anything exotic like install its own driver.

Furthermore where it finally does keel over its deep in the RDBSS (Redirected Drive Buffering Subsystem) http://msdn.microsoft.com/en-us/library ... 85%29.aspx At work we're currently tracking down with Microsoft what we believe is a bug in this Windows Component. Strangely enough we ran across this post on the VLC forums with a similar stack trace. While we still haven't come to a resolution with Microsoft I thought I'd at least pass on what we've found:

1. Obviously make sure you've gotten at least 2-3 full clean runs with Memtestx86 (you mentioned this was a new build) any type of memory corruption will result in you having a bad time.
2. Ensure the latest Windows Updates have been installed (We're troubleshooting this issue in WinServer 2012R2 so our links are Server specific, but many hotfixes are shared with 8.1) specifically check out these:
http://support.microsoft.com/kb/2953558
http://support.microsoft.com/kb/2899011
3. Validate that Offline Folders is out of the equation (for your setup you probably don't have this scenario)
4. If possible get a reproducing test case (if you find one we'd love to get a hold of it, as it stands for us we can only reproduce it with one of our development tools, but we believe it is not limited to this tool based on the error).

[Rémi Denis-Courmont]

This is an kernel mode crash, so it cannot be a VLC bug. As the trace implies, almost certainly a driver bug, namely in the SMB filesystem driver.

It could also be a hardware problem.