Valószínűleg több sorstársamnak is keserítette már meg az életét a fenti üzenet. Az Outlook kliens monoton homokórázik, a felhasználó csak ül, és a rendszergazdával karöltve szelíden bámulják a monitort.
Ashley Webb leírt egy történetet, ahol igen trükkösen kerítették be ezt a vadat.

Megjegyzés: a sztori – sajnos – nem egy univerzális módszer a probléma megszüntetésére. Csak érdekes megoldás egy szituációra.

Arról volt tehát szó, hogy a klienseknél teljesen sztochasztikusan bejött ez a hiba, miközben az Exchange szerver összes lényeges teljesítménymutatója teljesen rendben volt. (Innentől speciális a történet; a jelenséget ugyanis általában valamilyen szerveroldali/hálózati szűk keresztmetszet okozza.)
Webb szerette volna, ha a homokórázás alatt le tudja menteni az Information Store és a System Attendant által használt memóriatartalmakat (ADPlus.vbs), de ennek igen komoly akadálya volt a véletlenszerű előfordulás. Egész nap csak nem ülhet ott egy biorobot a szerver előtt, a telefonra koncentrálva…
Viszont rájöttek, hogy van egy mutató (Average RPC Latency), mely felugrik, ha bekövetkezik a hiba. Ez jó, mert a permormance monitorban rátettek egy alertet erre a mutatóra, mely egy küszöb átlépésekor automatikusan elindított egy programot – az ADPlus.vbs-t.
79 példányban. Ugyanis a dump elég hosszú ideig tartott, közben pedig az érték többször is leesett, majd visszaugrott. Itt egy garázsszagú buhera következett, összedobtak egy parancsfájlt, ez úgy indult, hogy megvizsgálta egy bizonyos txt fájl létezését: ha nem létezett, akkor létrehozta, majd futott tovább; ha létezett, akkor a szkript megállt.
És ennyi. Megszerezték a kívánatos memóriatartalmat.
A módszernek volt egy apró mellékhatása: a dump igen erőforrásigényes művelet, rendesen leterhelte az Exchange szervert. Amíg futott, addig nem is volt ideje kiszolgálni a klienseket.
Mit csinált helyette? Úgy van, kiszórta nekik is a címben szereplő üzenetet.:-)