
このページのスレッド一覧(全445スレッド)

内容・タイトル | ナイスクチコミ数 | 返信数 | 最終投稿日時 |
---|---|---|---|
![]() |
3 | 21 | 2018年2月25日 11:06 |
![]() |
1 | 1 | 2017年7月24日 19:34 |
![]() |
11 | 15 | 2017年7月16日 20:40 |
![]() |
3 | 6 | 2017年7月20日 02:07 |
![]() |
1 | 0 | 2017年7月10日 18:09 |
![]() |
1 | 1 | 2017年7月6日 21:10 |

- 「質問の絞込み」の未返信、未解決は最新1年、解決済みは全期間のクチコミを表示しています


長文で失礼します。
MSI A88X-G43 で 仮想マシン(vmware player)を使用すると
仮想マシン起動直後や、8時間程度たったときなど、不定期に
BSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生し、ホストOSごと落ちてしまいます。
A88X-G43で、vmware playerを使用すると同じように
BSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生している方いましたら教えてもらえませんか。
逆に、AMDプラットフォーム上で、vmware playerを使用しているが、全く問題ないという方がいたら
CPUやBIOS情報、マザーボード名などを教えていただけませんか。
いろいろと試行錯誤していると仮想マシンが起動している状態で、
[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、
この障害が発生する環境であれば必ず再現することがわかりました。
当初はハードの障害かとおもいUSB、拡張カードなど接続機器をすべて外し
CPU、メモリ、ハードディスク、電源、マウス、キーボードと最小構成にしてみても
vmware playerを実行中にBSODが発生します。
メモリ(windows OS付属ツール、memtest)やハードディスク(WD純正のハードディスク診断ツール)の
診断を行ってもハードの異常はないことも確認しました。
さらに、別に同型番のマザーボードA88X-G43を用意して、
まったく別の電源、別のCPU、別のメモリ、別のマウス、別のキーボード、別のハードディスクと
まったく共通する部品がないマシンを一台用意しました。(詳細については末尾を参照)
そのうえで、ハードディスクにOS(Windows 10)をオフラインでクリーンインストールしたところ
vmware player実行すると、やはり、BSOD が発生します。
ゲストOS自体もWindows 10をクリーンインストールしたのですが、やはり、BSOD が発生します。
よって、ハードの個体の問題でもOSの問題でもないようです。
ここで、BIOSが気になり、
最新の 3.C(3.12)を使用していたのですが、これを3.9にまで下げると、
まったく、BSODは発生しなくなりました。
上記のとおりA88X-G43が2枚あるのですが、2枚とも3.10以上だと
BSODが(CLOCK_WATCHDOG_TIMEOUT)発生し、3.9だと発生なくなります。
(不具合のある、V3.10(3.A)は2016/01/14にリリースされており
1年ぐらい前から発生しだしたという理由とも一致します)
AMDはAGESAコードという形でCPU、メモリコントローラー、HTバスコントローラーなどのmicrocodeを提供しています。
BIOS内のAMD AGESA バージョンを調べてみると 3.9と3.10(3.A)の間で大きく変わっているようです。
HWINFO64で、BIOSとAGESAのバージョンを調べると下記のようになっています。
■BSODになる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
■BSODにならないBIOS
(1)BIOS Version: V3.9
AMD AGESA Version: GodavariPI V1.0.0.0
BIOS Date: 04/20/2015
結論として、BIOSを、V3.10(3.A)以上に上げるとこの不具合が発生し
BIOSをV3.9にまでダウングレードすると、問題は全く発生しなくなります。
よって、BIOSを2016/01/14に作成されたV3.10以降に更新して
仮想マシンvmwareにて、AMD CPUの仮想命令セットAMD-Vを使用したときにBSODが発生するようです。
BSOD時の完全メモリダンプをwindbgで解析したところ、
4つコアがあるのですが、0,1,2番プロセッサは3番プロセッサの完了を待っており、
逆に、3番プロセッサは0,1,2番プロセッサの完了を待っており、デッドロックになっているように見えました。
この時3コアで実行されているプログラムはvmwareでした。
そこで、ためしにBIOS(3.12)の設定で0番プロセッサのみ有効にしてシングルコア状態でOSを起動し
vmwareを実行したところ、BSODは問題は発生しなくなりました。
でも、シングルコアではおそくて使用に耐えません。
BIOSを古いV3.9を使用すればよいかと思ったのですが、この古いバージョンだと
PCI-eにAsmedia 1061 SATA Hostcortrolerをつなげると、
別のBSODが頻発し、OSが起動すらできない状況で、
V3.12に上げないと使用できない状況で、V3.9にダウングレードして運用することもできず困っています。
問題が発生する、V3.10以降は、新CPU Carrizoに対応しているようですが、迷惑なことに古いCPUだと
CLOCK_WATHDOG_TIMEOUTが発生するという問題が混入してしまっているようです。
このマザーボードが対応する、carrizoコアのCPUは、Athlon X4 845、Athlon X4 835で、
GPUもなくクロックもそれまでの世代より、低くなっているという、
全く、メリットのないCPUで、AGESAコードが原因であれば、はなはだ迷惑な話です。
1点

しかし、AGESAコード内の CPUのMicrocodeは、下記の通り変化なくAGESAコードが問題としてもCPU以外のmicrocodeのようです。
#1台目の"AMD A10-7850K"は、BIOSのバージョンの3.9〜3.12は、"6003106"とすべて同じでした。
#2台目の"AMD A4-5300"は、BIOSのバージョンの3.9〜3.10は"6001119"と同じでした。
しかし、AGESAコードのバージョンは確かに変わっているのですが、これが原因とも断定できない状況です。
というのも、最近のUEFI BIOSは、かなり複雑化しており、圧縮して8MBに収めてあるのですが、
AGESAコード以外にも、200以上もあるモジュールの集合体でチップセット、
ストレージコントローラー、LANコントローラークロックジェネレータ、電源IC系など、
ありとあらゆるものプログラム(初期化コードと、firmwareドライバ)が
組み込まれているようです。
さらに、MSI社やBIOSメーカーのAMI社が作成しているモジュールなども多数組み込まれています。
BIOS 3.9と3.10のモジュールの差分を取ってみると
見るとAGESAコードだけではなく、数多くのモジュールに変更が入っているようです。(添付ファイル参照)
黄色のモジュールが変更されているのですが、BIOSバージョンの数バイト変わっているだけのものも数多くあり、
実際には修正・変更が入っているものは、少なくなると思います。
私と同じように、このマザーボードももしくはAMDプラットホームで
vmware実行時にBSOD が発生して困っている方いらっしゃいませんか。
ちなみに、2台あるA88X-G43のスペックは下記のとおりです。
#1台目
CPU情報
Processor Name: AMD A10-7850K
CPU ID: 00630F01
Extended CPU ID: 00630F01
CPU Brand Name: AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G
CPU Stepping: KV-A1
CPU Code Name: Steamroller/Kaveri
Microcode Update Revision: 6003106
#2台目
CPU情報
Processor Name: AMD A4-5300
CPU ID: 00610F01
Extended CPU ID: 00610F01
CPU Brand Name: AMD A4-5300 APU with Radeon(tm) HD Graphics
CPU Stepping: TN1-A1 (Trinity)
CPU Code Name: Piledriver/Trinity
Microcode Update Revision: 6001119
書込番号:21080581
0点

内容がディープすぎて分からない部分が多いのですが、今年に入ってBIOSのUpdateの有るマザーはA88XM-PLUSが行っている様です。こちらにかけてみるしかない感じがするんですが
何がやりたいのか分からないのですが、他の仮想マシン、例えばVirtualBoxを使ってみるとか?
取りあえず、VMWareは分かるんですが、ESXiでクライアントをぶら下げる程度に事しかやったことがないので(汗)
VMWare Communityのフォーラムにも同じ投稿が有ったので、こちらで回答が貰えるかは微妙じゃないですかね?
書込番号:21081312
0点

仮想PCでのOSは32ビットと64ビットどちらでしょうか?
取り敢えずA10-7850KではVM Ware Playerを動かしたことはありますが、32ビットのWindows XPなので参考にならないと思います。
書込番号:21082185
0点

訂正
「仮想PCでのOSは」を「ゲストOSは」に訂正します。
試してみるにしてもどちらか判らないのでは手間なので...
書込番号:21082982
0点

少しだけ試してみました。
ホストOSはWindows 10 Pro Insider Preview 16251 64ビット、VMWare Playerは12.5.7、ゲストOSはWindows 10 Pro Insider Preview 16232 64ビットです。
取り敢えずホスト側で「設定」を押しても何も起きませんでした。
数回の起動でも問題はありません。
ハードウェアは
ASUS A88XM-A(FW:3001、2016年4月8日公開)
CPU A8-7670K
メモリー PC3-19200 16GB(8GB×2、PC3-17000相当で使用)
他です。
Carrizoにも対応するバージョンです。
書込番号:21083548
1点

揚げかつパンさん
わたしも、仕事では、ESXi使っています。
ESXiはマシン1台が仮想マシン専用になり、もう一台使用するためのマシンがないと
いけないので、家で運用するのはちょっと難しいですね。
また、サーバメーカーごとにカスタムISOを提供している状態で、
PCなら何でも動くというものでもないようで、
普通の個人向けPCにインストールするには、対応するドライバ少ない
ことからも難しいとおもっていたのですが、
ひょっとしてこのA88X-G43でESXiが使用可能なのでしょうか。
しかし、ESXiはベアメタル型で非常に安定しています。
導入当初はハイパーバイザが落ちたら、ゲストOS全滅なので
大丈夫か心配しましたが、今まで1度も落ちたことないです。
ただ、バックアップが、結構難しく、時間もかかるので、
バージョンアップすると、起動しなくなるのではと
ハージョンアップできないというのが問題です。
一方Vmware Playerは、ゲストOSが落ちるのはしょっちゅうあります。
まあ、個人で作業用に使っているだけなので、ほかの人に迷惑を
かけるわけではないので、こんなもんかと思っています。
しかし、今回のようにVmware PlayerがホストOSを落とすというのは初めてです。
>取り敢えずA10-7850KではVmware Playerを動かしたことはあります
BIOSのバージョンとVmware Playerのバージョンはいくつかおしえてもらえませんか。
いままでのvmwareのマシンが結構あるので、それを使用したかったのですが、
VirtualBoxも試してみました。
vmwareではブルースクリーンになるホストOSの
[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]
という操作を何度繰り返してもBSODは発生しませんでした。
ところが、ゲストOSをシャットダウンすると、
ホストOSが BSOD 1A MEMORY_MANAGEMENT となり、落ちてしまいました。(涙)
(ただ、1回だけで、再現性がないです、ただ数回しかやっていないうちの1回なので、
何回か繰り返すとまた発生すると思います)
やはり、A88X-G43のBIOSの仮想関係に何らかの不具合がありそうです。
----------------------------------------------
uPD70116さん、揚げかつパンさん
検証ありがとうございます。
大変参考になりました。
>試してみるにしてもどちらか判らないのでは手間なので...
すいません書き忘れていました、
ゲストOSはWindows 10 Pro Creater Update 64bitを
オフライン状態でインストールしています。
BIOSファイル内のAGESA コードのバージョンを確認できる
UBU_v1.69-incl-Upd1_without-MMTool ツールで調査しました。
ASUS A88XM-A
BIOS Version: 3001 BIOS Date: 2016/04/08
Filename:A88XM-A-ASUS-3001.CAP
AMD AGESA CarrizoFM2r2PI V1.2.0.2X
揚げかつパンさんから教えてもらった、A88XM-PLUSのBIOSは下記の通りでした。
ASUS A88XM-PLUS
BIOS Version: 3004 BIOS Date: 2017/05/26
Filename:A88XM-PLUS-ASUS-3004.CAP
AMD AGESA CarrizoFM2r2PI V1.2.0.2X
一方、MSI A88X-G43は下記の通りです。
3.10(3.A)以降はBSODが発生します。
BIOS Version: V3.12(3.C) BIOS Date: 2016/08/10 ← BSOD発生
Filename:E7793AMS.3C0
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.4X
BIOS Version: V3.11(3.B) BIOS Date: 2016/04/08 ← BSOD発生
Filename:E7793AMS.3B0
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.3X
BIOS Version: V3.10(3.A) BIOS Date: 2016/01/14 ←このバージョン以降 BSOD発生する。
Filename:E7793AMS.3A0
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.2X
BIOS Version: V3.9 BIOS Date: 2015/04/20
Filename:E7793AMS.390
AMD AGESA Version: GodavariPI V1.0.0.0
A88X-G43のBIOS3.10はASUS A88XM-Aと同じ、AGESA CarrizoFM2r2PI V1.2.0.2Xなのに
ASUS A88XM-Aでは、BSODは発生しないようですが、なぜか MSI A88X-G43 ではBSODが発生します。
ASUSの AGESA V1.2.0.2X では問題は発生しないということは、
この問題はAGESA由来ではないということを示しているのではないかと思います。
さらに、MSIの方が、AGESAバージョンは2つも、おそらく何かの修正が入っている
新しいバージョンを使用しているのに、まったく謎なはなしです。
やはり、AGESAバージョン部分以外に、不具合があるということを示していると
考えるのが妥当なような気がします。
書込番号:21084320
0点

AMDプラットフォームで、vmware playerを使用している方で
BSOD CLOCK_WATCHDOG_TIMEOUTは発生せず、全く問題ないという方がおられましたら
CPUやBIOS情報、マザーボード名などを教えていただけませんか。
仮想ソフト Vmware workstation Player 12.5.7
ホストOS Windows 10 Pro Creater Update 64bit
ゲストOS Windows 10 Pro Creater Update 64bit
この環境で、ゲストOSを起動し、ホストOSにて
[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、
A88X-G43のBIOSが3.A以降であれば、必ずBSODが発生することがわかりました。
ゲストOS、ホストOSが違っても、発生したしなかったという
情報を教えていただけますとありがたいです。
とくに、チップセットとして
A88Xを使用されている下記のようなマザーボードでの情報が欲しいです。
ASRock FM2A88M-HD+ R3.0
MSI A88XM-E45 V2
ASUS A88X-PLUS/USB 3.1
GIGABYTE GA-F2A88XN-WIFI
書込番号:21088348
0点

ESXi6.5のパッチがでましたね。
書込番号:21088939 スマートフォンサイトからの書き込み
0点

ESXiのバッチ適用ってリスクか大きくて、適用できず運用しています。
インターネットにはつながっていないので、直接攻撃を受けることは少ないと思うのですが、
脆弱性を放置していることになり、不安の種です。
10台ぐらいのゲストOSがESXi上で動いていて、10人ぐらいの人が、
平日はバリバリ仕事に使っていて、障害がおこると、まったく仕事にならないという状況です。
ESXiはWindows Updateと違って、簡単に適用前に戻すことはできないようです。
簡単に早くバックアップを取るソフト、ハードは発売されているようですが、
びっくりするような値段でとても購入できません。
よって、converterなどで、バックアップしていますが、かなりの時間がかかります。
一度覚悟を決めて、みんなが使用しない休日に休日出勤して、バックアップを取ったうえ、
Updateをしたのですが、なぜか、Updateができないというメッセージが出てきて
結局アップデートできませんでした。(涙)
メーカーのカスタムISOからカスタムISOの次のバージョンへのアップデートで
ハードもメーカーが対応をうたっている型番で、あまり不具合が入る余地が少ない
アップデートだったのですが。
で、ESXiの話は、ここまで。
仮想ソフト Vmware workstation Player 12.5.7
を使用すると下記の操作で、ホストOSが落ちるという件です。
同じAGESA CarrizoFM2r2PI V1.2.0.2X を使用している
ASUS A88XM-A では問題は発生しないということは、
この問題はAGESA由来ではないということを示しているのではないかと思います。
さらに、MSIの方が、おそらく何かの修正や改善が入っている
AGESAバージョンは2つも上がった CarrizoFM2r2PI V1.2.0.4X をV3.12で使用しています。
ASUSの製品に不具合が起きるというのであればわかるのですが、
逆にMSIのみに不具合は起きています。まったく、謎なはなしです。
このことからも、これは、AGESAバージョン部分以外に、不具合があるということを
示していると考えるのが妥当なような気がします。
AMD CPUで仮想マシンvmware workstation playerの使用者は全体のPC利用者からすると、
少ないかもしれませんが、それなりシェアはあり、
A88Xチップセットを採用したマザーボードは
さまざまなメーカー(ASUS,GIGABYTE,ASRock,BIOSTARなど)から発売されているので、
共通のAGESAコード 1.2.0.2X(2016/01/14)に不具合が混入した場合は、もっと早く発覚していると思います。
現在のUEFI BIOSは非常に複雑で200以上のモジュールの組み合わせになっています。
具体的には下記のような種類に分けられるの様です。
(1)AGESA コード
(2)MSI社作成部分
(3)BIOSメーカーのAMI社作成部分
(4)さらに使用されているチップメーカー(IR社,Fintek社,Realtek社など)から提供されている部分
BIOSファイルをモジュール毎にファイルを分解して、バイナリDIFFを取ると
V3.9→V3.10では、(1)のAGESAコード以外の(2)(3)(4)などにも大きな変更が入っていることが確認できました。
原因は、下記の状況から、仮想命令セットAMD-V関係で、おそらく、排他処理がデッドロックしています。
(1)BSOD時の完全メモリダンプのwindbgの解析の結果、4つあるプロセッサの
0,1,2番プロセッサは3番プロセッサの完了を待っているように思われます。
逆に、3番プロセッサは0,1,2番プロセッサの完了を待っており、よって、永久に止まったままで、
いわゆる、典型的なデッドロックになっているように思えます。
この状態により、タイマーがタイムアウトして かなり優先度の
高い割り込みIRQL CLOCK_LEVEL (13) がかかり、
OSはこの割り込みをうけて、状況からシステムがロックしていると判断し、
BSOD CLOCK_WATCHDOG_TIMEOUTを発生させて、OSが自ら強制停止しています。
いわゆる ウォッチドクタイマーに引っかかっています。
ただ、状況的にこの割り込みがうまくかからないのか、
OSが自ら異常検知して強制停止するBSODまでいたらず、
単にロックとなってしまうこともあります。
(ロックとは、BSODとはならず、画面はそのままで、
マウスも、キーボードも動かず、リセットボタン、もしくは電断するしかない状態のことをいっています)
(2)BIOSにて、シングルプロセッサ設定にすると、発生しなくなる。
(シングルプロセッサでは一度に1つずつしか処理しないので、原理的にデッドロックは発生しずらくなります)
(3)ロックしているプロセスはvmware関係である。上記(1)の場合3番プロセッサ。
このVmware workstation Player 12.5.7を
使用すると下記の操作で、ホストOSが落ちる現象についてですが。
もう少し、情報が欲しいです。
[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、
必ずBSODが発生することがわかりました。
私と同じように、このマザーボードももしくはAMDプラットホームで
vmware実行時にBSOD が発生して困っている方いらっしゃいませんか。
また逆に、BSOD CLOCK_WATCHDOG_TIMEOUTは発生せず、全く問題ないという方がおられましたら
CPUやBIOS情報、マザーボード名などを教えていただけませんか。
とくに、チップセットとしてA88Xを使用されている下記のような製品の
情報あればありがたいです。(使用しているBIOSのバージョンを教えてください)
ASRock FM2A88M-HD+ R3.0
MSI A88XM-E45 V2
ASUS A88X-PLUS/USB 3.1
GIGABYTE GA-F2A88XN-WIFI
書込番号:21109459
0点

>free_manさん
ESXi上の動いているVMの(VMDKの)バックアップならば
http://www.unix-power.net/vmware/ghettoVCB_55.html
ghettoVCBスクリプト(無償)
が有名です。
お試しください。
# もっとも動いているVMのメモリやCPUレジスタまではバックアップできませんけど。
手元の検証用のマシン
AMD Ryzen 1700
ASRock AB350 Pro4
BIOS P3.00
Windows 10, 64-bit (Build 15063) 10.0.15063
に
VMware(R) Workstation 12 Player
12.5.7 build-5813279
を入れてみました。
VM(vCPU:4個, vMem:8GB)上にゲストOSとして、
CentOS Linux release 7.3.1611 (Core)
3.10.0-514.26.2.el7.x86_64
を
入れてみました。
特に問題はなさそうですよ。
書込番号:21111041
0点

>ESXi上の動いているVMの(VMDKの)バックアップならば
>http://www.unix-power.net/vmware/ghettoVCB_55.html
>ghettoVCBスクリプト(無償)
>が有名です。
>お試しください。
返事遅くなってすいません、ありがとうございます。
今度、試してみします。
ホストOS(win 10)がBSOD CLOCK_WATHDOG_TIMEOUTで必ず落ちる条件というのは
ゲストOSがWindows 10 Pro Creater Edition 64bitにて、下記の操作をしたときです。
[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]
また、ゲストOSを起動して、8時間ぐらいほおっておくとBSODが発生します。
Ryzen + CentOSでは、8時間ぐらいほおっておいても、BSODは発生しなかったのか
教えてもらうと助かります。
書込番号:21126283
0点

>free_manさん
ちょっとこの暑さですからね。
もう少しお待ちください。
書込番号:21140820 スマートフォンサイトからの書き込み
0点

free_manさん、初めまして。
私の環境でも同様の症状が発生しておりまして、解決のお役に立つのは難しいかとは思いますが、ひとまず事象報告だけさせていただきます。
私もAsRock A88M-G/3.1 + AMD A10-7890K + Win8.1 Pro x64の環境でVMware Workstation Pro 12を使用しておりますが、ホスト側で頻繁にCLOCK_WATCHDOG_TIMEOUTが発生します。
ほぼ確実に止まるのは、仮想化したWinServer2012R2の上でWSUSサービスを走らせ、クライアントからアクセスを掛けたタイミングです。
また、仮想化したWin8.1 Pro x64を動かしている際にも頻繁にホスト側でBSODが発生していました。
BSODが発生しないような設定がないかと色々試してはいるのですが、現状何らかのタイミングでBSODが発生する始末で手に負えませんね...
また、以前、AsRock A75-Pro4M + AMD A8-3870K + Win8.1 Pro x64の環境でも同様の現象は(現環境ほど頻繁ではないものの)発生していました。
AMD固有の問題なのか、AsRockマザーとの噛み合わせが悪いのか...と思っていましたが、スレ主様はMSIマザーを使用しておられるようですし、前者が濃厚そうですね。
書込番号:21168224 スマートフォンサイトからの書き込み
0点

なかなか、原因の切り分けのつかない厄介な不具合のようですね。
前にも書いたように、
現在のUEFI BIOSは非常に複雑で200以上のモジュールの組み合わせになっています。
具体的には下記のような種類に分けられるようです。
(1)AMD提供 AGESA コード
(2)マザーボードメーカー作成部分
(3)BIOSメーカーのAMI社作成部分
(4)さらに使用されているチップメーカー(IR社,Fintek社,Realtek社など)から提供されている部分
今までの話では、ASUSでは起きないので、MSI独自となる、(2)や(4)の可能性が高いと考えていました。
しかし、keinishi729さんの話を聞くと
逆に(1)や(3)の可能性がありますね。
ASRockのA88M-G/3.1 BIOSは、正式版とベータ版に分かれているようです。
ASRockのホームページからダウンロード調べたところ、下記の3つのバージョンがあるようです。
どのバージョン使用されていますでしょうか。
ベータ版
BIOS Version: 1.40C BIOS Date: 2016/12/09
Filename:A88MG311.40C
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.0X
正式版
BIOS Version: 1.40 BIOS Date: 2016/06/01
FileName:A88MG311.40
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.0X
BIOS Version:1.300 BIOS Date: 2016/1/20
FileName:A88MG311.30
AMD AGESA Version: CarrizoFM2r2PI V1.2.0.0X
BIOSメーカーはざっとバイナリデータを検索したところAMI社のように思えましたが、
AMI社でしょうか。
(BIOSをモジュールごとに、分解するとはっきりわかるのですが、そこまで、手が回りませんでした)
MSI社のA88X-G43場合、AGESAコードをGodavariPI V1.0.0.0までバージョンダウンすると、
BSODが起きなくなるのですが、残念ながらASRoskはA88M-G/3.1は
新しい、CarrizoFM2r2PI しか提供されていないようですね。
GodavariPI バージョンがためせれば、AGESAコードの問題かどうかの切り分けが
ついてきたとおもうのですが残念です。
あと、AsRock A75-Pro4MでBSODが発生していた時の、BIOSバージョンはわかりますか。
書込番号:21170553
0点

free_manさん
A88M-G/3.1(AMI BIOSでした)では1.30を、A75 Pro4-Mでは1.90を使用していました。
前者については1.40を使用していた際にも同様の症状が発生していたので、今回の現象についての改善は無かったようです。
後者については結構前のことですのではっきりとBSODが発生するタイミングなどは覚えておらず、あまりアテにはならないかもしれませんが...
また、現環境でBSODが発生する際、(あくまで傾向ではありますが)ホストOSとゲストOSで同時に負荷を掛けていると特に事象が再現しやすいように見受けられます。
例えばホスト側のWMPで音楽を再生しつつ、ゲスト側でWSUSの同期を行ったりするとすぐに落ちますし、前レスに記したホスト側からゲスト側WSUSへの更新プログラムのリクエストを行った時などもホスト・ゲスト両側からの負荷に当てはまるように思います。
逆にホスト側には触れず、ゲスト側だけで作業している間は多少ですが発生しづらいように感じますね。
とはいえゲスト側のみで作業していても落ちるときは落ちますし、長時間動かしていると結局は落ちるのですが...
一度他社仮想環境でも検証してみるべきかとは思っていますが、Intel環境では問題がない上、これまでVMwareを使用してきたが故の仮想マシン資産の変換の手間を考えると、他社製品への移行とまでは中々踏ん切りがつかないところですね...(^^;
書込番号:21170593 スマートフォンサイトからの書き込み
0点

free_manさん
追記です。
free_manさんが仰っていた「仮想マシン起動中にホストOSの″起動と回復″の設定を開くと必ず落ちる」事象ですが、こちらでも再現出来ましたのでお伝えしておきます。
仮想マシンの仮想化アクセラレーション設定を「自動」「AMD-V優先」「バイナリ変換優先」「バイナリ変換無効」で検証しましたが、全設定において、同様の手順を踏むと全て確実に落ちるようです。
また、OSの入っていない空の仮想マシンを起動した状態(OS not found状態)でも同様に再現しました(このケースでは設定画面は出てきたのですが、ウインドウのOKをクリックしたタイミングで応答しなくなりました)。
書込番号:21170616 スマートフォンサイトからの書き込み
0点

uPD70116さん、keinishi729さん
仮想マシンが起動している状態で、
ホストOSの[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]を押すと、この障害が発生する環境であれば、
この手順で必ず、ホストOSが、即BSOD、もしくはロックする件の続報です。
(ロックとは、BSODとはならず、画面はそのままで、
マウスも、キーボードも動かず、リセットボタン、もしくは電断するしかない状態のことをいっています)
新たに発生する、1つ条件がわかりました、
BIOS/UEFIのモードが"UEFIモード"の時のみ発生します。
uPD70116さん
下記の障害の発生しない、マシンのホストOSのBIOS/UEFIモードがどちらになっているか、
教えてもらえませんか。おそらくBIOSモードになっていると思います。
>ホストOSはWindows 10 Pro Insider Preview 16251 64ビット、
>VMWare Playerは12.5.7、ゲストOSはWindows 10 Pro Insider Preview 16232 64ビットです。
>取り敢えずホスト側で「設定」を押しても何も起きませんでした。
>数回の起動でも問題はありません。
windows 10がどちらのモードで動いているのかの確認方法は、
システム設定の「BIOSモード」が「レガシ」になっているときは
BIOSモード、「UEFI」となっているときはUEFIモードです。
その他のOSでは、bcdeditを管理者で実行してpathを確認という方法もあるようです。
windows ブートローダのpathが
\windows\system32\winload.exeであるならば、BIOSモード、
\windows\system32\winload.efiになってならば、UEFIモードのようです。
いままで、わかっている条件をまとめると下記のようになります。
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モード
Windows OS 32bitのUEFIモードという組み合わせはあまり一般的ではない様子。
BIOS/UFEIのモードはインストール時に決まり、基本あとからは変更できないようです。
しかし、windows インストール画面にBIOS/UEFIの明示的な選択画面、確認画面はありません。
インストール時のブートに使った、CDドライブ、USBメモリが
UEFIで始まる、UEFIデバイスか、従来のデバイスかにより、自動的に切り替わります。
よって、どちらかを使用しているか、あまり意識することがないです。
ユーザにとっての大きな違いは、2TB以上のパーティションからブートできるかできないかのようです。
keinishi729さん
ホストOSがwindows 7,8.1,10でUEFIモードの時、障害が発生することを確認しました。
ゲストOSはあまり関係ない様子というか組み合わせが大変で
すべてのパターンでは試せていないです。
わたしも、一番初めにゲストOSの仮想化アクセラレーションは
「自動」、「バイナリ変換」、「AMD-V」、「AMD-V/RVI」を
いろいろと切り替えてみたのですが、あまり影響はない様子でした。
書込番号:21175362
0点

これだけ、クリーンインストールで、何もインストールしていない状態で、
BSODを完全に再現方法もわかっているのに、
MSIによると不具合は確認できたが、AMDがAGESAコードを修正版を提供しないため、
対応できないのこと。
AMDに問い合わせると、MSI A88X-G43とASRock A88M-G/3.1で起きるといっているのに、
なぜか、わけのかわらんことに、ASUS A88X PLUSで、
テストしてBSODは起きないとしか回答してこない。
MSI A88X-G43 でテストしてくれと何度言っても、テストの結果をおしえてくれない。
BSODの時の完全メモリダンプも送っているのに、その解析結果も教えてくれません。
では、ASUS A88X PLUS の BIOSバージョンによる違いを聞くと、下記のように即答。
バージョン 3003 2016/04/08 AGESACarrizoFM2r2PI V1.2.0.2X BSODは発生しない
バージョン 2901 2015/12/25 AGESACarrizoFM2r2PI V1.2.0.2X BSODは発生しない
バージョン2801 2015/11/11 AGESACarrizoFM2r2PI V1.2.0.2X BSODは発生しない
それ以下のバージョンにはダウングレードできないという制限があるのでわからないとのこと。
uPD70116さん がASUS A88XM-A が起きないといっていましたし、
ASUS でおきないというのはどうもほんとらしいです。
しまいには、ASUSではおきないので、AMDの問題ではないようなことを言ってきます。
しかし、状況から明らかに、AMD でも、MSI A88X-G43 でBSODは確認できているのだか、
不具合を認めないという最悪の対応。
次はAMD CPUはやめようと思います。
(RyzenはよいのだけどあきらかなBSODも修正しないようなメーカーの製品はやめようとおもいます)
MSIも不具合は認めたけど対応してくれないし、マザーボードもトラブルのないASUSがよいのかな?
仕方がなく
CLOCK_WATCHDOG_TIMEOUTはUEFIモードの時のみに起こるということが分かったので、
通常は、インストール時に決まって切り替えはできないのですが。
下記の方法ですべての設定、アプリなど
そのまま保持した状態で、UEFIモードから、BIOSモードに切り替えました。
UEFIモードで、C:\はGPTフォーマットでインストールされていたので、
(1)現在のディスクをほかのディスクにイメージコピー、念のため起動することを確認
(2)現在のディスクを消去
(3)windowsのインストーラーをBIOSモード起動しMBRディスクとして
インストールしなおす。この時、C:\の容量を
現在のGPTのC:\と同じもしくは大きくしておく。
(4)コピーしておいたGPTのC:\のパーティションをBIOSモードでインストールしたMBRのC:\に
AOMEI Partition Assistant を使って上書きする。
(5)bcdeditを使用してブートローダーを更新
(たしか、BIOSモードでインストーラを起動して、[SHIFT]+[F10]で
cmdを出して変えたような、あとパーティーションをアクティブにしたようなしないような)
これで、次回起動時にBIOSモードに切り替わりました。
結果 vmwareを起動していても、BSOD CLOCK_WATCHDOG_TIMEOUT(101)は起きなくなりました。
ホストOSの[コントロールパネル]-[システムとセキュリティ]-[システム]-[システムの詳細設定]-
[詳細設定]タグの"起動と回復"の[設定(T)]を押してもBSODは発生しません。
しかし、vmwareを起動していなくても、BSOD 101 よりかなり頻度は少ないのですが、
DPC_WATCHDOG_VIOLATION(133)が1か月に1回ぐらい発生します。
BSODの完全メモリダンプを見てみるとhcmon.sys(vmwareのusb関連ドライバ)が
関係していて、やっぱりvmware関係がなんか怪しいです。
Widows8 以降では ドライバが10秒以上タイムアウトすると、
BSOD DPC_WATCHDOG_VIOLATIONが発生するようです、
windows8レスキューという、それ以前のWindows 7のように
この10秒タイマー監視をなくせるソフトでなくしてみたのですが、
BSODは起きませんが、1か月に一回ぐらい、完全にロックします。
よって、DPC_WATCH_DOG_VIOLATIONはドライバのロックを正しく
検知して、BSODにしているようで役に立っているようすです。
うーん、結局AMDのプラットホーム安定化できませんでした。
書込番号:21627775
1点

>free_manさん
長いので、すべてに目を通していません。
>仮想ソフト Vmware workstation Player 12.5.7
今日現在の最新は、14.1.1 です。
Ver.12まではBIOSブートがデフォルトでした。
※「*.vmx」ファイルに記述追加でUEFIブート可
bios.bootDelay = "5000"
firmware = "efi"
Ver.14からUEFIブートがデフォルトになっています。
バージョン、ゲストOSのブート方式を変更して
試されてないなら、試してみてください。
VMware Workstation Playerをバージョンアップして
起動させたゲストOSは、旧いバージョンでは起動
できなくなるので、バックアップをお忘れなく。
BIOS⇒UEFIブートに伴いゲストOSも再インストールが
必要になりますが、Windows 10標準の「MBR2GPT.exe」
で再インストールせずに変換することもできます。
AOMEI Backupper Standardで、GPTで初期化した仮想HDDに
現在のMBR HDDをクローンしても変換できます。
※どちらの場合もBIOSブートで起動し、変換が完了したら
シャットダウンして「*.vmx」ファイル]を書き換えます。
書込番号:21628073
0点

>free_manさん
お久しぶりです、keinishi729です。
ずっと原因調査してくださっていたようで、本当にありがとうございます。
結局のところ根本的な解決策は無く、ホスト側でのUEFIブートを諦めるしかないようですね...
当方の環境的に再構築がかなり面倒になりそうで、切り替えるか否かしばらく悩んで、もし決断できたら時間のあるときに決行しようかと思います...
>猫猫にゃーごさん
レスありがとうございます。
今回のスレッドの件はホスト側がUEFI環境であればゲスト側がBIOS/UEFIかに関わらず発生することをスレ主様と当方でも確認済みですので、どうやらゲスト側の環境切り替えでは解決が出来ないようです。
最新バージョンはまだ検証出来ておりませんので、時間が出来たら改めて検証したく思います。
書込番号:21628963 スマートフォンサイトからの書き込み
0点



マザーボード > ASUS > TUF Z270 MARK 1
いったん組み上げて、
立てた状態で作業することがあると思います。
そんなとき、
何かの表示でネジでも落としたりすると、
マザーボード上のカバー(のようなもの)の内側に落ち込んだりして、
拾い出すのに苦労するでしょう。
少なくとも私は、
そんな思いをしました。
1点

立てた状態でも,寝かせた状態でも,ネジ等の落下にはご注意を・・・
通電中なら,大事に・・・・至る恐れも!
書込番号:21067889
0点



マザーボード > ASUS > ROG STRIX Z270F GAMING
レビューにも書きましたが困っていますので、ご教授くださいm(_._)m
構成内容は以下の通りです。
3,4年前に使っていたZ87機が故障したため、まるごと新規に購入、買い換えました。
マザー : ASUS STRIX Z270F GAMING
CPU : Core i7 7700K
メモリ : W4U2400PS-8G(PC-19200 8GN X 2)
グラボ : MSI GeForce GTX 1080Ti Gaming X 11G
ケース : CARBIDE AIR 540 white
空冷 : 虎徹 SCKTT-2000
OS : Windows10 Home 64bit
AI SUITE3をインストールしたせいか、マザボ自動設定の4.7GHzのOCしたためなのか、判り兼ねますが、たまにWindows10起動時にブルースクリーンが出るようになってしまいました。
CPUの設定をデフォルト値に戻してもたまに出ます。
再起動するとブルスクは治って、ディスクチェックが自動的に入って、それ以降は安定してゲームできるようになりますが、あまり気持ちのいいものではありません。
付属ソフトを入れてブルースクリーンなんて、こんなマザーボードははじめてです。
以前はAsrock Extreme6 Z87で、至極安定しておりました。
以上、上記の現象は一番何が原因として考えられるでしょうか?
ちなみに購入は3日前です。
1点

・メモリーは起動後はまず一安心しますが、そのあとにはちゃんとmemtest+など試験して安心を確かめることが重要です。
・電源の記載が無いようです。 流用でしょうかね?
書込番号:21047014
1点

>再起動するとブルスクは治って、ディスクチェックが自動的に入って
「まるごと新規に購入」でしたか ,真逆の,SSD/HDDポン付け???
CPUとソケットの接触不良・・・ピン曲がり/折れ等はありませんか?
書込番号:21047061
0点

一口にブルースクリーンといっても内容は様々です。
その内容が不明では明確な回答は難しいです。
ブルースクリーンならエラーコード、エラーの出ているモジュール名等の情報が表示されているので提示してください。
それから無視している電源、ドライブ、この辺りも関係してくる可能性も否定は出来ません。
書込番号:21047093
2点

ブルースクリーンが発生したときにメモリーダンプ作成状況や
原因になったファイル名が表示される。それを元に原因を
追求されたら。
書込番号:21047095
0点

返信みなさんありがとうございます。
SSDはサムスンのm.2 SSD 860EVO 512GBを新規に購入しましたが、
電源はご指摘の通り、4年前に買ったコルセアのAX860iの流用です。
memtest86+は現在走らせています。もう少し時間がかかりそうですが今の所
75% まで終了して、ERROR 0です。
書込番号:21047102
0点

16GBメモリーなら1Pass 1.5時間はかかると思います.。
書込番号:21047129
0点

1つだけ。
memtest中はメモリーのOCは解除でしょうか? つまり2133MHz動作かな?
できれば通常起動時と同じクロックでやって欲しかったですが、通常時2400MHz → memテスト時2133Mhzでは出にくくなりますね。
書込番号:21047143
0点

PASS1終わりましたが、ERROR 0だったので、次4.7GHzもやってみます。
みなさんが指摘されている、電源も怪しそうだし、コルセアのスリーブケーブルも
内部的にダメになっているのかも・・・
書込番号:21047167
0点

>マザボ自動設定の4.7GHzのOCしたためなのか、
情報がハード構成だから、
CPUのオーバークロックでCore i7 7700Kを4.7GHzにしたらブルースクリーンも出るよねと単純になら言うかも知れないね。
CPUコア電圧は自動のままだろうか?
CPU Load-line Calibrationは?
CPU Current Capabilityは?
CPUキャッシュ倍率?も倍率を上げていくと電力供給と発熱に関係してくる様だからね。
虎徹 SCKTT-2000でCPUが冷やされるよりもCPU内にインテルが封入したグリスで熱が逃げ難かったりしてね。
室温はエアコンで制御してるのか、部屋の窓を開けて自然の風で自動制御か気に成るところ。
私は、H110i GTXで定格のCore i7 7700Kを放熱・冷却してるけど自然の風の自動制御では室温がアツイ!!
(Z170搭載のASUSのマザーボードを使ってるけどね。)
あっ、Core i7 875K搭載の倍率下げたパソコンも稼働しているか・・・。
液晶モニタの台数で室温は違ったりする気もするけどね。
書込番号:21047202
2点

Windows10がブルースクリーンになったときのイベントビューアを参照すると
Kernel-Powerが原因になったみたいですが、
これは電源が原因という意味ですかね?
書込番号:21047737
1点

いま再びASUSの自動設定やってみたのですが、4.7GHzどころか4.6GHzすらOCすると、
ブルースクリーンすら出ずに、固まってしまいます。
いま私のこのハードウエア構成は、たったこれだけの耐性もないのでしょうか?
やはり自分が使いまわした電源、簡易水冷、スリーブケーブル、すべてを見直すべきでしょうか?
ちなみに室内はクーラーで25度に保っています。
書込番号:21047808
0点

KP41が出る場合は色んなケースを一つずつ潰すしかないです。
自分場合はメモリーのOCをやめてCPUのOCだけなら止まりました。 → メモリーを他機種へ交換ですべて使えるようになりました。
http://freesoft.tvbok.com/windows7/another_kp41/kp41_checkpoint_2015.html
書込番号:21047831
2点

私のASUSのZ170 PRO GAMINGはCore i7 7700Kを定格使用中だけど、
CPU Load-line Calibrationは Level 2(1〜7の2段目だね)
CPU Current Capabilityは 100%
になっている。
さて、
CPU Core Voltageの方は 自動だったかな?
4.7GHz・・・100MHz×47倍にするなら、
CPU Core Voltageをオフセットで『 + 』で『0.050V〜0.100V』盛ってしまうとCPUの温度がキツイかな?
CPU Load-line Calibrationは レベル4かレベル5にするとか、
CPU Current Capabilityを120%にしてみるとか。。。
Core i7 7700Kの定格で室温25℃で虎徹 SCKTT-2000がCPU温度とCPUコア温度を最高何℃になるんだろうね。
HD Graphics 630を使う設定の場合はHD Graphics 630の方にもLoad-line CalibrationやCurrent Capabilityで盛って安定を探すとか。
しかし、私のエアコンなしの窓開放の状態でH110i GTXの温度が36.5℃って人間の体温並みだね。
Core i7 7700Kを定格でCPU稼働率数%程度か5%前後か・・・。
Corsair Linkでパフォーマンス設定でファン1900rpm程度かポンプは3000rpm程度か。
ところで、CPU Cache Ratioは定格なら最大が42倍なのかな、
CPU Cache Ratioの倍率を上げると電力も喰らうし発熱も増える。
さて、BCLK周波数が100.00MHzなら良いが100.25MHzとか100.50MHzと増えると、
メインメモリの周波数まで増えてしまうハズだから注意だね。
>いま再びASUSの自動設定やってみたのですが、4.7GHzどころか4.6GHzすらOCすると、
えっ、自動設定って定格設定じゃなくOCの自動設定?
書込番号:21048061
2点

ありがとうございます。Windows10立ち上がりました。
>星屑とこんぺいとうさん
>あずたろうさん
あずたろうさんと星屑とこんぺいとうさんの設定をそのまま生かして
メモリーのOCをやめる。
Ai Overclock TunerをXMPに変更
XMP DDR4-2400 15-15-15-35-1.20V
CPU Core Ratio 46(4.6GHz)に
CPU Core Voltageをオフセットで + で0.050V
DRAM FrequencyをDDR4-2400MHzに変更
CPU Load-line Calibrationは レベル4に変更
CPU Current Capabilityを120%に変更
に変更すると、見事立ち上がってちょっと感動しました。
勉強になります。今までは、自動設定って定格設定じゃなくOCの自動設定でしておりました。
とにかくよかったです!
書込番号:21048215
0点



マザーボード > ASRock > H110 Pro BTC+
7/3に予約したのに、未だ発送されてない。
発売後7/8に確認したら、10日までには届けますと返信が有ったが
結局届いてない。
発売済みなら多少わかるが、予約だよ?
どうなってるのか確認中だが
回答無し
1点

私と同じような事例ですので、書かせていただきます。
2日に注文して7日配達予定がいつの間にか7日から10日予定に変更されてました、まあ、仕方ないと思っていたのですが昨日夕方になっても発送されないためアマゾンに電話しましたが分からないとの回答でした。
書込番号:21035610 スマートフォンサイトからの書き込み
0点

>きれい いちごぱんさん
やはり同様の方がいらっしゃったんですね。
予約出来たら、発売日か発売日から数日で入手出来ると思いますよね。
Amazonからの回答ですが
私的に要約すると
「300円分のクーポンやるから1〜2ヶ月待ってろ。」でした。
任天堂switchとかの発売時に
予約を受け付けておいて、1〜2ヶ月後にお届けです。
とか言えるんですかね。
因みに、この商品(H110 pro BTC+)は2017/7/7発売です。
書込番号:21036726
0点

そしてふざけた値段で販売開始始めました。
仕入れ担当は何を考えているのだろう・・・
書込番号:21048826
1点

>和尚がTwoさん
凄いですね。
Amazon 2017/7/17 0:55 70,000円
あれかな、
大量のクレーム→
サポートから仕入れ部門にクレーム→
担当が即納させるためにムチャな仕入れ値で仕入れ→
在庫分で損害を取り戻すための金額を計算→
70,000円
仕入れのミスをお客様へ還元
(勝手な私的推測です)
因みに、届きました。
気になっていた所をちょっと。
PCI-Ex1スロットに連続でライザーカード(x1-x16)を刺すと
隣りのライザーカードと干渉スレスレ、
ちょっとUSBケーブルにテンションがかかると干渉しそうですが、
手持ちのライザーカードで干渉するのはUSBのシェル?外側同士
(外側のハンダ足と外側)なので大丈夫そうですが、
念の為、万が一のショートを予防するのがよさそうなので
ライザーカードにビニールテープを一巻して使う事にしました。
マイニング用なので安定性のテストだ〜。
書込番号:21048947
1点

>はち74さん
それは、よかったですね。
自分は13枚もいるのかなぁと考えて、ASUSで7枚刺しでいいのではと悩んでいます。(マザボは所有)
あと、狭いのはフラットケーブルで刺す仕様で考えたのかな。
やっぱり元を取るための値段かなとは思っていましたが。
予約販売できないのは困りますよね。
書込番号:21051882
0点

>和尚がTwoさん
本当に新発売の予約はしっかり管理してほしいです。
Amazon普通の値段に修正されてますね。
H110ProBTC+はethos(マイニング用Linux)の会社と協力して作った?らしく
13個のPCI-E、IntelのLAN、基盤上のパワースイッチ、リセットスイッチなど、
こだわりを感じます。
このethosでは13枚のRXが稼動するらしいです(噂)
Windowsではドライバの関係からRX系は8枚まででドライバの更新待ちだそうです。
8枚でも十分だと思いますが。
PCI-Eの間隔は机上では大丈夫で、実機でも大した問題では無いと判断されたのかな?
個人的にリグでのレイアウトを考えると、PCI-Eは後ろに寄っている方が使い勝手が良いと感じます。
テスト中に気がついた事
オンボードグラフィックを使おうとすると、PCI-E側のグラボと何かが干渉するのか
一枚マイニング出来ず、Afterburnerもその一枚は設定不可になります。
オンボードは使わずPCI-E2(x16スロット)は映像出力と兼業になるみたいです。
書込番号:21056343
0点



マザーボード > MSI > Z270 GAMING PRO CARBON
1カ月ほど前に、以前使用していたGIGABYTEのM/BでBIOS書き換え失敗してしまい(MAIN BIOSで失敗したまま、BACKUP BIOSでも失敗し、起動不能に。。。)、急遽すぐに入手できたコチラのM/Bを使い始めました。
基本的な部分は問題なく動作していますが、1カ月使用して判明した不具合を報告しておきます。
仕様は画像に記載の通りで、OSはWin10 64bitです。
BIOSは1.54(Beta)を使用していますが、1.40(リリース版最新)でも同じ症状です。
@ 画像1枚目 Above 4G memory/Crypto Currency mining を有効にすると、Microsoft 基本ディスプレイアダプターが適応されるシーンで、画面真っ暗(ディスプレイ信号有り)で、何も出来なくなります。
この不具合に気付いたのは、セーフモード起動した際、通常通りブートしたな〜と思いきや最後の最後で画面真っ暗、何も出来なくなったことでした。
あと、再現したのはWin10インストールUSBを起動させた時、ブート後画面真っ暗に。。。
GTX960やIntel HD Graphics 630のドライバを使用している状態では問題なく画面表示されるんですが、これらのドライバを使わないシーンでこの現象が起きます。
ちなみに、Win10起動中にデバイスマネージャーで、あえてMicrosoft 基本ディスプレイアダプターを適応したところ、適応直後は問題なく画面表示していましたが、再起動したら画面真っ暗状態になりました。
VGAはELSAのGTX960を使用していますが、Intel HD Graphics 630(7700K内臓GPU)でも同じ事が起きますので、VGAとの相性問題では無さそうです。
UEFI BIOSをdefaultにしたところ、画面表示出来るようになったので、設定項目を片っ端から無効にしていったところ、これに行きつきました。
セーフモードやインストールUSB等のブートで画面真っ暗になった際は、慌てず一度リセットしてこの設定を無効にしてください。
A こちらは該当する方がかなり少ないと思いますが、AdaptecのRAIDカードを使用する際の不具合です。
RAIDカード(ASR8405)側のファームウェアが33072以降の場合で、画像2枚目の設定、Windows 8.1/10 WHQL Support を有効にすると、BIOSすら起動出来なくなるものです。
PCの電源ONすると、すぐに画像3枚目の画面表示になり、そのまま何も起こりません。
復旧するためにはCMOSクリアして、Windows 8.1/10 WHQL Support が無効の設定に戻すしかありません。
このM/B、CSM 有効/無効の設定項目が無く、Windows 8.1/10 WHQL Support と連動している様なんです。
Win10の高速ブートが自動的に無効になってしまうし、セキュアブートも使えないので、困っています。
この件はMSIサポートの方に連絡して、Adaptecの新しいファームウェアには対応出来ていないこと、今後のBIOSバージョンアップで対応するので、それまで待って欲しいと解答を得ています。
どうしても、Windows 8.1/10 WHQL Support を有効にしたければ、Adaptecのファームウェアを33067にすることで起動出来る様になります。
このファームウェアの違いはM/BのUEFI BIOSメニューにAdaptecの設定項目を追加する(新しいファーム)か、しないか(33067以前)なので、Adaptecの要求にM/BのUEFI BIOSが対応出来ないんでしょう。
GIGABYTEのM/Bでは対応出来ていたので、こんなところでハマるとは思っていませんでした。。。
結局、悩んだ結果、Adaptecのファームウェアは最新(33173)に、Windows 8.1/10 WHQL Support は無効にして使用しています。
PC起動や休止状態からの復帰時にGTX960とAdaptecのPOST画面が毎回表示され、非常に鬱陶しいですが、仕方なく使用しています。。。
ちなみに、画像4枚目の AUTO CLR_CMOS を有効にしておくと、今回の事象が起きた際、ATX電源のスイッチをOFFにして15秒ほど待ち、再度ONしてPC起動すると、画像3枚目の状態でブートはしないんですが、そのまま待ってると、自動的にリブート&CMOSクリアされて、UEFI BIOSがブート出来る様になります。
このM/B、CMOSクリアジャンパがVGAカードに隠れてしまうので、クリア作業が非常にやりにくいんですよね。。。
自動でCMOSクリアしてくれる、この機能は便利に使わせてもらってます♪
1点

この板に書くのもいいですが、まず MSIへ報告して、
問題の改善を要求する方がいいです。
書込番号:21023693
0点


クチコミ掲示板検索
新着ピックアップリスト
-
【Myコレクション】これ買っちゃおっかな〜
-
【欲しいものリスト】次のMini-ITX このPCケースに惚れそう
-
【欲しいものリスト】Core Ultra 3 205出たらこのくらいで組みたい
-
【欲しいものリスト】グラボなし
-
【欲しいものリスト】白で可愛くVRゲームを快適に
価格.comマガジン
注目トピックス

(パソコン)
マザーボード
(最近3年以内の発売・登録)





