AMD APU(A10-7850K、A4-5300)にてvmwareを実行していると、ホストOSにBSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生します

[TTL_COMS]

AMD APU(A10-7850K、A4-5300)にてvmwareを実行していると、ホストOSにBSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生します。

AMD の APU (A10-7850K、A4-5300)にて、仮想マシンソフト(VMware Workstaton Player 12.5.7)

で仮想マシンを実行中に、ホストマシンのOS(win8.1/win10)が

ブルースクリーン CLOCK_WATCHDOG_TIMEOUT(101)が発生します。

仮想マシンの起動直後に発生したり、数時間から8時間程度たった後に発生します。

いろいろと試行錯誤していると仮想マシンが起動している状態で、

[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-

[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、

この障害が発生する環境であれば必ず再現することがわかりました。

同じ仮想マシンのファイルをIntel CPUのマシンでも動かしていますが、

1度もブルースクリーンは発生していません。

1年前ぐらいから、CLOCK_WATCHDOG_TIMEOUTが発生しだしました。

(VMware Workstaton Player 12.5.7以前も発生していました)

今年の1月ぐらいに、発生時にはVMwareを実行しているときということがわかりました。

上記の必ず発生する手順は最近1週間前にようやくわかりました。

ちなみに、vmwareを実行していないときは、このようなBSODは全く発生せず、

安定しています。

当初はハードの障害かとおもいUSB、拡張カードなど接続機器をすべて外し

CPU、メモリ、ハードディスク、電源、マウス、キーボードと最小構成にしてみても

vmware playerを実行中にブルースクリーンが発生します。

メモリ(windows OS付属ツール、memtest)やハードディスク(WD純正のハードディスク診断ツール)の

診断を行っても異常はありません。

さらに、別に新しいハードディスクを用意してOS(Windows 10)をオフラインで、

クリーンインストールしたものを用意して、そのうえでvmware playerを実行しましたが、

同様にブルースクリーン CLOCK_WATCHDOG_TIMEOUTが発生しました。

(このとき、ハードディスクは上記windows10をインストールしたもの以外、何もつないでいません)

マザーボードはMSIのA88X-G43を使用しています。

そこで、別に同型番のマザーボードA88X-G43を用意して、

まったく別の電源、別のCPU、別のメモリ、別のマウス、別のキーボード、別のハードディスクと

まったく共通する部品がないマシンを一台用意しました。(詳細については末尾を参照)

そのうえで、ハードディスクにOS(Windows 10)をオフラインでクリーンインストールしたところ

vmware player実行すると、やはり、ブルースクリーン CLOCK_WATCHDOG_TIMEOUTが発生します。

よって、ハードの個体の問題でもOSの問題でもないようです。

ここで、MSIのマザーボードのBIOSが気になり、

最新の 3.C(3.12)を使用していたのですが、これを3.9にまで下げると、

ブルースクリーンは発生しなくなりました。

上記のとおりA88X-G43が2枚あるのですが、2枚とも3.10以上だと

ブルースクリーンが(CLOCK_WATCHDOG_TIMEOUT)発生し、3.9だと発生なくなります。

(1年ぐらい前から発生しだしたという理由とも一致します)

BIOSのAMD AGESA バージョンを調べてみると 3.9と3.10(3.A)の間で大きく変わっているようです。

HWINFO64で、BIOSとAGESAのバージョンを調べると下記のようになっています。

■ブルースクリーンになるBIOS

   (1)BIOS Version:                           V3.12(3.C)

     BIOS Date:                              08/10/2016

     AMD AGESA Version:                      CarrizoFM2r2PI  V1.2.0.4X

　(2)BIOS Version:                           V3.11(3.B)

     BIOS Date:                              04/08/2016

     AMD AGESA Version:                      CarrizoFM2r2PI  V1.2.0.3X  

   (3)BIOS Version:                           V3.10(3.A)

    BIOS Date:                               01/14/2016

    AMD AGESA Version:                       CarrizoFM2r2PI  V1.2.0.2X  

■ブルースクリーンにならないBIOS

  (1)BIOS Version:                           V3.9

    AMD AGESA Version:                       GodavariPI      V1.0.0.0   

    BIOS Date:                               04/20/2015

結論として、ASESAバージョンが

"CarrizoFM2r2PI  V1.2.0.2X" 以降では

vmware実行時にブルーススクリーン CLOCK_WATCHDOG_TIMEOUT(101)が発生し、

"GodavariPI V1.0.0.0" では発生しません。

AGESAコード由来の不具合と思われます。

AMD CPUは "Microcode Update Revision"と "AMD AGESA Version"があるようです。

ちなみに、Microcodeは、

#1台目の"AMD A10-7850K"は、BIOSのバージョンの3.9～3.12は、"6003106"とすべて同じでした。

#2台目の"AMD A4-5300"は、BIOSのバージョンの3.9～3.10は"6001119"と同じでした。

よって、Microcodeはブルースクリーンに関係していないと考えています。

AMD APUで、同様のAGESAのバージョン由来の問題(CLOCK_WATCHDOG_TIMEOUT)が、

おきている方おられますでしょうか。

あと気になった点ですが、

Intel系だと、Microcodeだけで、プロセッサアーキテクチャごとに

別のものになるのですが、AMD AGESA Versionの最新のものは、

古いAPUに適用しても動作する互換性があるのかどうか不明です。

今の状況では古いKaveriAPUに最新のCarrizoAPU用が適用されているようなんですが。

それぞれの、マシンの詳細な構成は下記のとおりです。

A88X-G43 #1台目

CPU情報

[General Information]

  Processor Name:                         AMD A10-7850K

  Original Processor Frequency:           3700.0 MHz

  Original Processor Frequency [MHz]:     3700

  CPU ID:                                 00630F01

  Extended CPU ID:                        00630F01

  CPU Brand Name:                         AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

  CPU Vendor:                             AuthenticAMD

  CPU Stepping:                           KV-A1

  CPU Code Name:                          Steamroller/Kaveri

  CPU OPN:                                ****************

  CPU Thermal Design Power (TDP):         95.1 W

  CPU Platform:                           FM2r2 (uPGA)

  Microcode Update Revision:              6003106

  Number of CPU Cores:                    4

  Number of Logical CPUs:                 4

A88X-G43 #2台目

CPU情報

[General Information]

  Processor Name:                         AMD A4-5300

  Original Processor Frequency:           3400.0 MHz

  Original Processor Frequency [MHz]:     3400

  CPU ID:                                 00610F01

  Extended CPU ID:                        00610F01

  CPU Brand Name:                         AMD A4-5300 APU with Radeon(tm) HD Graphics   

  CPU Vendor:                             AuthenticAMD

  CPU Stepping:                           TN1-A1 (Trinity)

  CPU Code Name:                          Piledriver/Trinity

  CPU OPN:                                ****************

  CPU Thermal Design Power (TDP):         65.2 W

  CPU Platform:                           FM2 (PGA)

  Microcode Update Revision:              6001119

  Number of CPU Cores:                    2

  Number of Logical CPUs:                 2

[TTL_COMS]

情報の追加です、BSOD CLOCK_WATCHDOG_TIMEOUT(101)発生時に完全メモリダンプを

取得して、windbgで解析してみました。

結論から言うと、vmwareが関係しているようなのですが、

根本的な原因まではたどり着けませんでした。

プロセッサ間の(メモリ?)の排他制御の問題のようなに思えたので、

ためしにBIOSから0番プロセッサのみ有効にしてシングルコア状態で、

vmwareを実行したところ、8時間たっても問題は発生しなくなりました。

でも、遅くて使用にたえないです。

AMDは仮想化がAMD-Vとintelとは別なので、そのあたりの問題なのでしょうか。

AGESAコードには、CPU以外の、チップセットやメモリコントローラー、

HTバスコントローラなどの様々なmicrocodeが含まれているようで、やはりそれらが影響しているのではないかと思われます。

詳しくは下記のとおりです。

CLOCK_WATCHDOG_TIMEOUTの解析方法について、下記のサイトの情報を参考にwindbgで解析しました。

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x101---clock-watchdog-...

https://blogs.msdn.microsoft.com/ntdebugging/2011/10/26/debugging-a-clock_watchdog_timeout-bugcheck/

https://www.sysnative.com/forums/bsod-kernel-dump-analysis-debugging-information/270-class-101-0x101...

環境は下記のとおりで、OS、ドライバともすべて最新版を適用済みです。

CPU: AMD A10-7850K

マザーボード: MSI A88X-G43

OS:Windows 8.1

vmware workstation player 12.5.6

BSODの原因は、CLOCK_WATCHDOG_TIMEOUT (101)で、これは、CPUの1つのコアがハングアップしてしまい。

タイムアウトとなり、OSが強制的にBSODを発生させているようです。

原因はデッドロックなどの可能性があるようです。

Arg1: 0000000000000030, Clock interrupt time out interval in nominal clock ticks.

Arg2: 0000000000000000, 0.

Arg3: ffffd001fafe4180, The PRCB address of the hung processor.

Arg4: 0000000000000003, The index of the hung processor.

Arg4はプロセッサの番号を示しており3番目のプロセッサ(0オリジン)がロックしたとのことです。

Arg3のffffd001fafe4180 はハングアップしたプロセッサの情報が格納されているとのことで、

調べてみると、たしかに、Arg3と3番プロセッサの情報の!prcb 3のアドレスが一致しており、

たしかに3番プロセッサの処理になにか問題があるようです。

0: kd> !prcb 3

PRCB for Processor 3 at ffffd001fafe4180:

Current IRQL -- 0

Threads--  Current ffffe00145f90080 Next ffffe0014424c380 Idle ffffd001faff02c0

Processor Index 3 Number (0, 3) GroupSetMember 8

Interrupt Count -- 00084317

Times -- Dpc    00000072 Interrupt 00000085

         Kernel 0000167a User      0000116d

そこで、3番プロセッサのスレッド情報を調べてみたのですが、

下記のとおり、スタックが表示されず情報を得ることができませんでした。

ただ、Imageはvmware-vmx.exeになっており、やはりvmwareに原因がありそうです。

(過去のBSODの完全ダンプものも調べてみまたが、停止したコア同じようにImageがvmware-vmx.exeが実行されており、スタックが表示されませんでした)

3: kd> !thread

THREAD ffffe00145f90080  Cid 2ac4.2bcc  Teb: 00007ff665d94000 Win32Thread: fffff90140bc32a0 RUNNING on processor 3

Not impersonating

DeviceMap                 ffffc000fe1980e0

Owning Process            ffffe00147cc2400       Image:         vmware-vmx.exe

Attached Process          N/A            Image:         N/A

Wait Start TickCount      10235          Ticks: 599 (0:00:00:09.359)

Context Switch Count      3937           IdealProcessor: 2           

UserTime                  00:00:00.203

KernelTime                00:00:02.328

Win32 Start Address 0x00007ff6666d06a0

Stack Init ffffd00028017c10 Current ffffd00028017250

Base ffffd00028018000 Limit ffffd00028011000 Call 0000000000000000

Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5

Child-SP          RetAddr           : Args to Child                                                           : Call Site

00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0

レジスタもすべて0で何も情報が得られませんでした。

3: kd> r

rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000

rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000

rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000

r8=0000000000000000  r9=0000000000000000 r10=0000000000000000

r11=0000000000000000 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0         nv up di pl nz na pe nc

cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000

00000000`00000000 ??              ???

ここから、解析している上記のサイトでは、!threadで得られる下記のスタックのアドレス情報をdpsでダンプして、

原因を見つけているようですが、数百行もスタックが並び、空のものもあれば、断片的に様々なプログラムが呼ばれており

ここから、どのようにどのプログラム理解して解析してよいのか見当がつかずお手上げ状態です。

Base ffffd00028018000 Limit ffffd00028011000 Call 0000000000000000

3: kd> dps ffffd00028011000 ffffd00028018000

ffffd000`28011000  00000000`00000000

～

ffffd000`28014ac0  00000000`00000000

ffffd000`28014ac8  fffff800`6a06c0df nt!RtlSetBitsEx+0xa3

ffffd000`28014ad0  00000200`00000000

ffffd000`28014ad8  00002800`00000010

ffffd000`28014ae0  0000019e`00000000

ffffd000`28014ae8  00002601`00000000

ffffd000`28014af0  ffffffff`ffffffff

ffffd000`28014af8  fffff800`6a10710a nt!RtlFindClearBitsAndSetEx+0x122

ffffd000`28014b00  00000000`00000172

～

ffffd000`280165e0  00000000`00000001

ffffd000`280165e8  00000000`00000001

ffffd000`280165f0  fffff801`6747b980 rcraid+0x72980

ffffd000`280165f8  00000000`00000000

ffffd000`28016600  00000000`0000002f

ffffd000`28016608  fffff800`6a7a9ff2 hal!HalRequestSoftwareInterrupt+0xd3

ffffd000`28016610  fffff800`6a315180 nt!KiInitialPCR+0x180

ffffd000`28016618  ffffe001`3e9d3030

ffffd000`28016620  00000000`0000002f

ffffd000`28016628  fffff800`6a7a9ff2 hal!HalRequestSoftwareInterrupt+0xd3

～ 300行ぐらい続く

そこで、プロセッサの割り込みの情報を調べてみると、0,1,2番プロセッサは3番プロセッサの完了を待っているように思われます。

逆に、3番プロセッサは0,1,2番プロセッサの完了を待っており、デッドロックになっているように思えます。

3: kd> !ipi

IPI State for Processor 0

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     0 [Running]

IPI State for Processor 1

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     2 [Frozen]

IPI State for Processor 2

    As a sender, awaiting IPI completion from processor(s) 3.

    TargetCount          1  PacketBarrier        1  IpiFrozen     2 [Frozen]

IPI State for Processor 3

    As a receiver, unhandled requests are pending from processor(s) 0, 1, 2.

    TargetCount          0  PacketBarrier        0  IpiFrozen     5 [Target Freeze]

    From processor 0, active request of type: packet ready

        WorkerRoutine fffff8006a0a7d80 (nt!EmpCheckErrataList)

        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0

    From processor 1, active request of type: flush multiple range

        Flush Count 1  Flush List ffffd00027f6cc08  (dp ffffd00027f6cc08 l1)

    From processor 2, active request of type: packet ready

        WorkerRoutine fffff8006a0a7d80 (nt!EmpCheckErrataList)

        Parameter[0] 0  Parameter[1] 0  Parameter[2] 0

ためしにBIOSから0番プロセッサのみ有効にしてシングルコア状態で、

vmwareを実行したところ、8時間たっても問題は発生しませんでした。

ここで、問題の仮説として2つ考えました。。

1)排他制御に問題があり、デッドロックが発生している。シングルコアにすると、同時に2つのプログラムは

走らなくなるので、この問題は解消する。

(昔、マルチコアが出始めたころ、アプリのプログラムで、シングルコアではまったく不具合出なかったものが

マルチコアになった途端に、不具合が頻発するという経験がありました。このときも排他がデッドロックしていたり、あるいは逆に

排他が入ってなかったため、複数コアが同時に同じメモリにアクセスして、メモリを破壊していました)

2)3番プロセッサのvmware-vmx.exeに不具合があり、スタック、レジスタが破壊してしまい、ロックしてしまう。

3番プロセッサの完了を待っている0,1,2番プロセッサのうち0番プロセッサがタイムアウトの割り込みがかかり

ブルースクリーンになる。

参考にしたサイトでも、この現象は書いてありましたが、不具合による、スタック、レジスタの破損では

なさそうな解説でした。

各プロセッサの割り込みの状況を調べてみると下記の通りでした。

0番プロセッサのみ13で、そのほかは0でした。

数字の大きい方が、優先度が高いようで、

13は、下記のページによるとCLOCK_LEVELで、Clock timerをしめしているようです。

https://blogs.msdn.microsoft.com/doronh/2010/02/02/what-is-irql/

0番プロセッサでCLOCK_LEVELという高い割り込みが入ったことを示しているようです。

0: kd> !irql 0

Debugger saved IRQL for processor 0x0 -- 13

0: kd> !irql 1

Debugger saved IRQL for processor 0x1 -- 0 (LOW_LEVEL)

0: kd> !irql 2

Debugger saved IRQL for processor 0x2 -- 0 (LOW_LEVEL)

0: kd> !irql 3

Debugger saved IRQL for processor 0x3 -- 0 (LOW_LEVEL)

ここで、0番プロセッサのスタックをトレースすると、下記のようになっており、ここでブルースクリーンが呼ばれたようです。

0: kd> kv

# Child-SP          RetAddr           : Args to Child                                                           : Call Site

00 fffff800`6dff3c88 fffff800`6a187ec5 : 00000000`00000101 00000000`00000030 00000000`00000000 ffffd001`fafe4180 : nt!KeBugCheckEx

01 fffff800`6dff3c90 fffff800`6a066c27 : 00000000`00000000 00000000`00000000 00000000`00000001 fffff801`00000000 : nt! ?? ::FNODOBFM::`string'+0x116f5

02 fffff800`6dff3d20 fffff800`6a7ac67f : 00000000`00000001 00000000`00000001 fffff800`6a7f89b0 00000000`00000001 : nt!KeClockInterruptNotify+0x787

03 fffff800`6dff3f40 fffff800`6a0f6743 : fffff800`6a7f8900 fffff800`6a11169f 00000000`00000000 00000000`00000000 : hal!HalpTimerClockInterrupt+0x4f

04 fffff800`6dff3f70 fffff800`6a16772a : fffff800`6a7f8900 00000000`00000001 00000000`00000000 00000000`00036400 : nt!KiCallInterruptServiceRoutine+0xa3

05 fffff800`6dff3fb0 fffff800`6a16809b : 00000000`00000000 fffff800`6a315180 00000000`00000001 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xea (TrapFrame @ fffff800`6dff3e70)

06 ffffd000`24946e50 fffff800`6a03cde8 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0xfb (TrapFrame @ ffffd000`24946e50)

07 ffffd000`24946fe0 fffff800`6a3c05b2 : 00000000`02c50090 ffffd000`24947b00 00000000`00000005 ffffe001`497318c0 : nt!KeFlushProcessWriteBuffers+0x16c

08 ffffd000`249470e0 fffff800`6a3b14ed : 00000000`00000000 00000000`00036400 ffff07ab`96a10988 00000000`00000000 : nt!ExpGetProcessInformation+0xe2

09 ffffd000`24947380 fffff800`6a3b0b25 : 00000000`02c50090 00000000`0352e1f0 00000000`00000005 00000000`00008000 : nt!ExpQuerySystemInformation+0x975

0a ffffd000`24947a40 fffff800`6a171ab3 : ffffe001`48854080 00000000`00000474 00000000`00da7a64 00000000`0362f61c : nt!NtQuerySystemInformation+0x49

0b ffffd000`24947a80 00007ffe`6b980a1a : 00000000`777f59ad feeefeee`feeefeee 00000000`00ea0100 00000000`0352eaa0 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`24947a80)

0c 00000000`0352ddd8 00000000`777f59ad : feeefeee`feeefeee 00000000`00ea0100 00000000`0352eaa0 00000000`00000005 : ntdll!NtQuerySystemInformation+0xa

0d 00000000`0352dde0 00000000`777e621b : 00000000`02bd0000 00000000`02bd0000 00000000`00036000 00000000`0352df30 : wow64!whNT32QuerySystemProcessInformationEx+0x8d

0e 00000000`0352de30 00000000`777e90be : 0000a08b`ecb7f5c8 00000000`00010000 00000000`0362f514 00000000`00000000 : wow64!whNtQuerySystemInformation_SpecialQueryCase+0x7f7

0f 00000000`0352e1e0 00000000`777ea45b : 00000000`00000000 00000000`777ea160 00000000`7ecdd000 00000000`7ecdb000 : wow64!whNtQuerySystemInformation+0xce

10 00000000`0352e220 00000000`77761dc5 : 00000023`7786c3bc 00000000`00000023 00000000`0362f5f4 00000000`00000000 : wow64!Wow64SystemServiceEx+0xfb

11 00000000`0352ead0 00000000`777f21aa : 00000000`00000000 00000000`77761574 00000000`00000000 00000000`777f2390 : wow64cpu!ServiceNoTurbo+0xb

12 00000000`0352eb80 00000000`777f20e2 : 00000000`00000000 00000000`00000000 00000000`0352fd30 00000000`0352f1d0 : wow64!RunCpuSimulation+0xa

13 00000000`0352ebd0 00007ffe`6b908dab : 00000000`00000000 00000000`777f1f70 00000000`00000000 00000000`00000000 : wow64!Wow64LdrpInitialize+0x172

14 00000000`0352f110 00007ffe`6b908c8e : 00000000`0352f1d0 00000000`00000000 00000000`7ee1f000 00000000`00000000 : ntdll!_LdrpInitialize+0xcb

15 00000000`0352f180 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

ここで、手詰まり状態です。

[TTL_COMS · Accepted solution]

MSI A88X-G43で、vmware workstation playerを使用すると同じように

BSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生している方いましたら教えてもらえませんか。

逆に、AMDプラットフォーム上で、vmware workstaion playerを使用しているが、全く問題ないという方がいたら

CPUやBIOS情報(バージョン)、マザーボード名などを教えていただけませんか。

[TTL_COMS]

仮想マシンが起動している状態で、

ホストOSの[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-

[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、この障害が発生する環境であれば、

この手順で必ず、ホストOSが、即BSOD、もしくはロックする件の続報です。

(ロックとは、BSODとはならず、画面はそのままで、

マウスも、キーボードも動かず、リセットボタン、もしくは電断するしかない状態のことをいっています)

MSI以外にも、ASRockのマザーボードでも発生することがわかりました。

発生が確認できたマザー

・MSI    A88X-G43   BIOS Version: V3.10(3.A)以降

    CPU AMD A10-7850K

        AMD A4-5300

・ASRock A88M-G/3.1 BIOS 1.30

    CPU A8-7670K

また、ホストOSのBIOS/UEFIのモードがUEFIモードのとき起きることがわかりました。BIOSモードでは発生しません。

今までわかっている条件をまとめると下記のようになります。

1)AGESAコード CarrizoFM2r2PIの世代以後

以前ではなく以後です、つまりBIOSアップテートにより、発生するようになります。

2)ホストOSのCPU数が、マルチコア(2コア以上)

　ホストOSのmsconfig.exeのブートタグ、ブートの詳細オプションで、

　プロセッサの数を1個に制限すると、BSODは全く発生しない。

　ホストOSのプロセッサ数を1個に制限するため、同時にゲストOSのプロセッサ数も1個と設定することになります。

　(ホストOSのBIOSで、制限できるCPUであればそれでもよさそうでした)

3)ホストOSのBIOS/UEFIのモードがUEFIモード

MSIに問い合わせると、AMDがまだ発売されているCPUなのに、

AMDのmicrocodeである、AGESAコードの修正しないというひどい対応を取っているとのことです。

BIOS 3.9以前のAMD AGESA Version: GodavariPI V1.0.0.0 に

戻すとこの不具合は発生しなくなるので、技術的には修正可能なはずです。

そもそも、AGESAなどのMicrocodeはハードに不具合(errata)があっても、

回避する目的で作られたはずです。

その昔、IntelのCPUが割り算の回路を間違えていたが、ハード的なもので修正できず、

全品交換となったということから、最悪ソフト的に回避できるようにということで、

導入されたものだと思います。

しかし、そのMicrocode自体に不具合が混入し、

さらに、なおさないというのは本末転倒なはなしです。

一人程度のユーザーがこのようなことを伝えても、AMDはスタンスを変えないようです。

同じ症状の方がいたら、AMDに不具合を修正するように、サポートに陳情してもらえませんか。

いくらRyzen Threadripper,EPYCが革新的で早くて、コストパフォーマンスがよくても、

ブルースクリーンのような致命的な欠陥が見つかっても、

発売終了にもなっていないのに、なおさないようなAMD製CPUの購入は避けたほうが良いようです。

過去にIntel社でも仮想マシンを使用するとBSODが発生するという同様の不具合がありましたが、

速やかにMicrocodeの修正版を提供しきちんと対応しています。

https://support.microsoft.com/ja-jp/help/975530/stop-error-message-on-a-windows-server-2008-r2-based...

上記はmicrosoftの修正に含まれると書いてありますが、実際にはintel cpuの不具合で、インテルが作成した、

不具合を回避するのMicrocodeをOS起動時にWindows OSがCPUにアップロードしています。

仮想マシンを使用する方は、AMDは使い物にならないのでintel製CPUを使用したほうが良い結論になりました。

AMDが修正してくれることが一番望ましいのですが、

AMDがErrataと認めて、情報を公開し、OSもしくは、vmware側で対処してもらえる可能性はあるのでしょうか。