We're seeing some very strange filter driver behavior (also
observable on standard MS WDK Minifilter sample). A "freeze" occurs
on some Windows XP sp2 versions (especially images dated ~2007,
including all patches) On other versions (like clear old XP sp2) this
problem is not observed.

note:

- Problem can be replicated easily on XP SP2 with system files of
version 5.1.2600.2978 (explorer right click on "fltmgr.sys" and see
version tab)

- Problem is not seen if SP3 is installed

Problem description :

1. Take WDK minspy sample (src/filesys/minifilter/minispy)
2. Build driver & console app, put together driver & app & inf.
Change inside inf "Instance1.Flags = 0x1"
to "Instance1.Flags = 0" for auto attachment to logical drive
3. Install minspy driver
4. Start minispy ("net start minispy"
5. All seems good at this stage

6.Change in driver source (minispy)

Original mspyLib.c:

- since line numbers may differ across various WDK versions, grep for:
in function VOID SpyLog (__in PRECORD_LIST RecordList)

565: KeAcquireSpinLock(&MiniSpyData.OutputBufferLock, &oldIrql);
566: InsertTailList(&MiniSpyData.OutputBufferList, &RecordList->List);
567: KeReleaseSpinLock(&MiniSpyData.OutputBufferLock, oldIrql);
Changed:
565: KeAcquireSpinLock(&MiniSpyData.OutputBufferLock, &oldIrql);
566: //InsertTailList(&MiniSpyData.OutputBufferList, &RecordList->List);
567: KeReleaseSpinLock(&MiniSpyData.OutputBufferLock, oldIrql);
568: SpyFreeRecord (RecordList);

I.e. tell driver to not store log and immediately free block

7. Rebuild driver
8. Place it to system32/drivers (overwrite old one)
9. "net start minispy"
10. Here we go.. freezing

Best seen in MSVS 2005 — open project — two/three times switch
debug/release on toolbar. MSVS 2005 (depending from machine speed) can
freeze 10-30 seconds to minutes !

11. net stop minispy
12. All freezes vanish (MSVS 2005 doesn't freeze at all)

- if we release memory immediately after request big freezes appear in
the system. (possibly on ExFreeToNPagedLookasideList)

- the main question is — what the heck is this ? a bug in minifilter system ?

In a real driver , it is a pain ( impossible / quite hard ) to do
remitted memory frees ( as seen in minispy by default ).

The " magic " solution of remitted frees seems spooky without further
insight. Anyone understand what's going on ?

many of the driver problems especially coding related will be best answered at osr online ntdev lists
have you tried posting over there

we here would normally be more adept in answering if you post a .sys that we could net start attach detach softice and windbg without source :P

Yes I'd posted it up at OSR , MSDN and even IDA's board .. also to my friends list who write plenty of drivers ( production ) .. no answers yet.

Definitely seems to be something strange given that it disappears and behaves as expected in SP3.

I can certainly think of extracting relevant portions from the overall code and try to build a project ( and the compiled target ) so that you can have a go at it.

565: KeAcquireSpinLock(&MiniSpyData.OutputBufferLock, &oldIrql);
566: InsertTailList(&MiniSpyData.OutputBufferList, &RecordList->List);
567: KeReleaseSpinLock(&MiniSpyData.OutputBufferLock, oldIrql);
Changed:
565: KeAcquireSpinLock(&MiniSpyData.OutputBufferLock, &oldIrql);
566: //InsertTailList(&MiniSpyData.OutputBufferList, &RecordList->List);
567: KeReleaseSpinLock(&MiniSpyData.OutputBufferLock, oldIrql);
568: SpyFreeRecord (RecordList);

at brief look i see: you have removed >
566: //InsertTailList(&MiniSpyData.OutputBufferList, &RecordList->List);
then call
568: SpyFreeRecord (RecordList);

can this your prob?

No, thats just to tell the driver to not store log and immediately free block

then you also can remove lines 565,567 as useless.
and only bug can be inside 568.
& only way to find it id DEBUGG..

/edit:
either try put 568 between 565 567

then remove also code for spinlocks, as it's not needed, and leave only SpyFreeRecord... Also when working with lists in mt environment, it's much better to use ExIterlockedInsertTailList which will make your code look smaller, and can be used at any irql level.

Basically by freeing record at this point you could alter some other parts of the code. I didn't check minifilter sample at all, but, those examples are provided with detailed comments, and are intended to show and teach how to properly write driver, not to remove/add parts to them randomly I know that writing fs filter driver takes some time, but eventually when you write it once, with all fastio/dispatch routine properly set, you can use it later on as a template for later fs filter projects.