大手サーバメーカが2007年にWin2000のサポートを打ち切った件で悲しい真相

システムはSTOP 1Eエラーメッセージで再起動することがあります。
影響を受ける構成

システムは、以下のIBMサーバーのいずれかです。

    システムx3800、タイプ8866、任意のモデル
    システムx3850、タイプ8864、任意のモデル
    システムx3950 E、タイプ8879、任意のモデル
    システムx3950、タイプ8878、任意のモデル

このヒントはオプションに固有のものではありません。

システムは、以下の少なくとも1つで構成されています。

    Microsoft Windows 2000 Advanced Server、任意のサービスパック
    Microsoft Windows 2000 Datacenter Server、任意のサービスパック
    Microsoft Windows 2000 Server、任意のサービスパック
    Microsoft Windows 2000 Server 64ビット版、任意のサービスパック

注：これは、ネットワークオペレーティングシステムがハードウェアとソフトウェアのすべての組み合わせで動作することを意味するものではありません。

詳細については、互換性のページを参照してください：

    http://www.ibm.com/servers/eserver/serverproven/compat/us/

追加情報

次のURLにあるMicrosoft Knowledgebaseの記事KB924439を参照してください。

    http://support.microsoft.com/kb/924439

インテルRデュアルコアXeonプロセッサと大容量キャッシュを搭載したシステムでは、影響を受けるIBMシステムが使用可能になった後、Microsoft Windows 2000 ServerでSTOP 1Eリセットが発生することが判明しました。

ユーザーは、Microsoftサポートに連絡して追加の支援を受ける必要があります。

　　　　　STOP 0x0000001E (parameter1, parameter2, parameter3, parameter4)
　　　　　 KERNEL_MODE_EXCEPTION_NOT_HANDLED

この問題は、Windows 2000 Serverのカーネルが、大規模なL3キャッシュを搭載したマルチコア・プロセッサに対応していないことによるものです。

対応方法
　Windows 2000 Serverは、大規模なL3キャッシュを搭載したマルチコアのプロセッサをサポートしませんので2007年5月25日をもってHA8000/270(CF,DFモデル)における Windows 2000 Serverのサポートを中止とさせていただきます。Windows Server 2003にて運用してください。

　 尚、既にHA8000/270(CF,DFモデル)を購入頂いてWindows Server　2000をご使用頂いているお客様については継続して対応します。但し、技術情報924439 に起因する問題には対応できません。

    Xeon 7100シリーズ プロセッサを搭載している
    Microsoft Windows Server 2003またはWindows 2000 Serverを導入する
    Windowsソケット通信サービス（Winsock）を利用する

2007年7月現在、対象となる機種は次の通りです。

    ProLiant ML570 G4（Xeon 7100 搭載モデル）
    ProLiant DL580 G4（Xeon 7100搭載モデル）

詳細
対象機種に記載されたProLiantサーバに、Microsoft Windows Server 2003またはMicrosoft Windows 2000 Serverを導入すると、Windowsソケット通信サービス（Winsock）利用時に、モジュール名afd.sysで以下のブルースクリーンが発生します。

Windows Server 2003で発生するメッセージ：
STOP 0x0000008E (parameter1, parameter2, parameter3, parameter4)
KERNEL_MODE_EXCEPTION_NOT_HANDLED

Windows 2000 Serverで発生するメッセージ：
STOP 0x0000001E (parameter1, parameter2, parameter3, parameter4)
KERNEL_MODE_EXCEPTION_NOT_HANDLED

この問題は、Windows Server 2003またはWindows 2000 Serverのカーネルが、大規模なL3キャッシュを搭載したマルチコア・プロセッサに対応していないことによるものです。詳細は、マイクロソフト社のナレッジ・ベースKB924439を参照してください。

マイクロソフト社KB924439
http://support.microsoft.com/kb/924439/en-us  Non-HPE site

解決方法
Windows Server 2003：
この問題は、Windows Server 2003サービスパック１で解決されています。該当機種にWindows Server 2003を導入する時は、Windows Server 2003サービスパック１を適用するか、サービスパック１相当であるWindows Server 2003 R2 をご利用下さい。

Windows 2000 Server：
Windows 2000 Serverは、大規模なL3キャッシュを搭載したマルチコアのプロセッサをサポートしません。これらのプロセッサを搭載したサーバは、Windows Server 2003 SP1（またはそれ以降）にアップグレードする必要があります。

On a Microsoft Windows 2000-based computer, you receive an error message that resembles the following:
STOP 0x0000001E (parameter1, parameter2, parameter3, parameter4)
KERNEL_MODE_EXCEPTION_NOT_HANDLED
This problem occurs if the computer uses a very fast processor, and the computer has a large L3 cache.

CAUSE

This problem occurs because of a hard-coded breakpoint in the Afd.sys process. This breakpoint occurs because the processor continues to run code before an asynchronous procedure call (APC) occurs. This timing problem occurs only on very fast processors when they are used together with earlier operating systems.

Note The APC is queued in the Afd.sys process.

After the APC is queued, a series of commands are run. These commands include a check to determine the following:

    Whether the event in the IO Request Packet (IRP) is signaled
    Whether the return from the IoCallDriver routine was "non-error"

If the event is not signaled, and if the IoCallDriver routine returns a "non-error" status, a code section is implemented that calls the DbgBreakPoint routine. The DbgBreakPoint routine i
s implemented when either the event or the IoCallDriver routine behaves incorrectly. When the DbgBreakPoint routine is called in this area of code, this resembles a situation in which the BugCheck routine is called. In both situations, the code should not continue to run past the point that is specified in the instructions if the assumption of incorrect behavior is true.

A stack trace of the failure shows that the event is signaled at the time that the DbgBreakPoint routine occurs. However, the DbgBreakPoint routine occurs because the event was not signaled at the time of the check.

  		call	[NTOSKRNL.EXE!KeWaitForSingleObject]
jmp	L000257E3
L000257A2:
mov	ecx,C0000000h
and	eax,ecx
cmp	eax,ecx
jz 	L000257E3
lea	eax,[ebp-18h]
push	eax
call	[NTOSKRNL.EXE!KeReadStateEvent]
test	eax,eax
jnz	L000257E3
push	SSZ0002563C_________________________________
call	jmp_NTOSKRNL.EXE!DbgPrint
pop	ecx
push	ebx
push	SSZ00025670__AFD__IoCallDriver_returned_STAT
call	jmp_NTOSKRNL.EXE!DbgPrint
pop	ecx
pop	ecx
push	SSZ000256CC_________________________________
call	jmp_NTOSKRNL.EXE!DbgPrint
pop	ecx
call	jmp_NTOSKRNL.EXE!DbgBreakPoint
L000257E3:
xor	eax,eax