Memory leak in NTFS.SYS von W2K SP4 mit Rollup 1 ?

[zahni 542]

Ich habe heute zum 1. Mal den Event 2019 bei unserem W2K PDC erlebt.

 

( http://www.eventid.net/display.asp?eventid=2019&eventno=661&source=Srv&phase=1 )

 

Der Server hat alle aktuellen Patches und das Rollup 1 (allerdings noch nicht die 2. Version)

 

Nun habe ich mal auf einem anderen, weniger kritischen Server, das Debugflag für poolmon aktiviert und etwas interessantes beobachtet:

 

Scheinbar gibt das tag "ntfr" keinen Speicher frei sondern genehmigt sich bei fast jedem lesenden Zugriff auf eine Datei neuen Speicher:

 

Memory: 3833356K Avail: 2852048K  PageFlts:   208   InRam Krnl: 4428K P:89084K
Commit: 822508K Limit:5760980K Peak: 858228K            Pool N:48228K P:89532K
System pool information
Tag  Type     Allocs            Frees            Diff   Bytes       Per Alloc

[b]Ntfr Nonp      66522 (   0)     11002 (   0)    55520 3554272 (     0)     64[/b]
File Nonp    1962240 (1527)   1929029 (1530)    33211 5360320 (  -480)    161
NtFs Nonp      94361 (   0)     65453 (   0)    28908 1855168 (     0)     64
Ntfn Nonp      37231 (   0)      8323 (   0)    28908 1850752 (     0)     64
MmCa Nonp     176419 (   2)    148293 (   2)    28126 3596096 (     0)    127

 

Der diff ist bereits bei 55520 (ich remote mal nach Viren suchen lassen) und wird nicht kleiner.

 

Der Speicherverbrauch ist nicht hoch, kann sich aber nach ein paar Monaten summieren.

 

Allerdings musste ich gleichzeitig zur Installation vom Rollup 1 Symantec Antivirus 10.01 installieren. Auf dem Server wird allerdings nur bei "Erstellen von Dateien" gesucht, um die Datensicherung nicht zu gefährden... Liegt also vielelicht auch an SAV.

 

Andererseits ist ein entsp. Fehler auch bei W2K3 bekannt:

 

http://support.microsoft.com/default.aspx?scid=kb;en-us;891004

 

Vielleicht kann das jemand bestätigen, der keinen Virenscanner auf dem Server hat ?

 

Ich werde jedenfalls, wenn sich das Verhalten hier über Nacht bestätigt einen Case bei MS öffnen.

 

-Zahni

[zahni 542]

Habe gerade mal nachgeschaut: In der 2. Version vom Rollup 1 ist die ntfs.sys nicht neuer und hat das gleiche Build.

 

-Zahni

[zahni 542]

So, ich habe den Fehler jetzt wieder gehabt:

 

Memory: 1048084K Avail:  463516K  PageFlts:  3729   InRam Krnl: 4556K P:84292K
Commit: 530528K Limit:3531708K Peak: 530372K            Pool N:189964K P:85228K
System pool information
Tag  Type     Allocs            Frees            Diff   Bytes       Per Alloc

[b]LSwn Nonp       8157 (  41)      1874 (   0)     6283 128675840 (839680)  20480[/b]
SavE Nonp    2896699 (   0)   2896287 (   0)      412 12065696 (     0)  29285
NtFC Nonp     390992 (   0)    302408 (   0)    88584 11338752 (     0)    128
MmCm Nonp       1107 (   0)         5 (   0)     1102 5386528 (     0)   4887
File Nonp   53075976 ( 116)  53056798 (  68)    19178 3165152 (  7680)    165
LSwi Nonp          1 (   0)         0 (   0)        1 2293760 (     0) 2293760
LScn Nonp       3678 (  21)       476 (   0)     3202 1946816 ( 12768)    608
Irp  Nonp     247459 (   0)    244518 (   0)     2941 1216544 (     0)    413
CcSc Nonp    4720062 (   0)   4716593 (   0)     3469 1110080 (     0)    320
Mdl  Nonp    1446677 (  23)   1438200 (   0)     8477 1085056 (  2944)    128
LSrf Nonp     270318 (   0)    266652 (   0)     3666  938496 (     0)    256

 

Info:

 

LS?? - <unknown> - LM server allocations

LSac - <unknown> - BlockTypeAdminCheck

LSas - <unknown> - BlockTypeAdapterStatus

LSbf - <unknown> - buffer descriptor

LScd - <unknown> - comm device

LScn - <unknown> - connection

LSdb - <unknown> - data buffer

LSdc - <unknown> - BlockTypeDirCache

LSdi - <unknown> - BlockTypeDirectoryInfo

LSep - <unknown> - endpoint

LSfn - <unknown> - BlockTypeFSName

LSlf - <unknown> - LFCB

LSlr - <unknown> - BlockTypeLargeReadX

LSmf - <unknown> - MFCB

LSmi - <unknown> - BlockTypeMisc

LSnh - <unknown> - nonpaged block header

LSni - <unknown> - BlockTypeNameInfo

LSop - <unknown> - oplock break wait

LSpc - <unknown> - paged connection

LSpm - <unknown> - paged MFCB

LSpr - <unknown> - paged RFCB

LSrf - <unknown> - RFCB

LSsc - <unknown> - search(core)

LSsd - <unknown> - BlockTypeShareSecurityDescriptor

LSsf - <unknown> - BlockTypeDfs

LSsh - <unknown> - share

LSsp - <unknown> - search(core complete)

LSsr - <unknown> - search

LSss - <unknown> - session

LStb - <unknown> - table

LStc - <unknown> - tree connect

LSti - <unknown> - timer

LStr - <unknown> - transaction

LSvi - <unknown> - BlockTypeVolumeInformation

LSwi - <unknown> - initial work context

LSwn - <unknown> - normal work context

LSwq - <unknown> - BlockTypeWorkQueue

LSwr - <unknown> - raw work context

LSws - <unknown> - BlockTypeWorkContextSpecial

 

 

Fehler: Server nimmt keine SMB-Verbindungen mehr an,

 

der Tag LSwn "leakt" wie verrückt memory ?

 

Kennt das jemand ?

 

-Zahni

[zahni 542]

Ein Case mit "Urgent" ist eröffnet. Werde berichten, wenn was sinnvolles rauskommt.

 

-Zahni