ユーザーモードのクラッシュダンプがある場合のCPUモデルを確認

Question

私のアプリケーションのクラッシュダンプがあります。私のアプリは、私がそこに持っているいくつかのSSSE命令を実行しようとしている "無効な命令"と言うユーザーのために失敗します。

WinDBGでは、CPUモデルを調べることで、その命令セットを見つけて、命令セットをサポートするか、アプリケーションの最小ハードウェア要件を更新できますか？

はここ!cpuidの出力です：

CP F/M/S Manufacturer  MHz 
0 16,4,3 <unavailable> 3000 
1 16,4,3 <unavailable> 3000 
2 16,4,3 <unavailable> 3000 
3 16,4,3 <unavailable> 3000 

Googleは役立つかもしれないと言うコマンドの残りの部分の印刷「が見つかりません輸出」（errrec、cpuinfoを、SYSINFO！！！）。

Answer 1

あなたは間違いなくここに多くの情報を得ていません。ダンプには通常、生のCPU情報のすべてはありませんが、製造元の文字列を少なくとも参照する必要があります。ああ、今ここで作業しなければならないことを見てみましょう...

CPの列には論理プロセッサ番号が記載されていますので、4つの論理プロセッサを持つシステムを扱っていることがわかります。クアッドコア、またはおそらくHyperThreadingを備えたデュアルコアである可能性があります。

F/M/Sは、ファミリ/モデル/ステッピングであり、プロセッサを識別するための一般的でかなり標準的な方法です。 AMDが言うように：

プロセッサ家族は、ソフトウェアまたはハードウェアの目的のために、いくつかの一般的な定義を持っているグループに属するように、1つの以上のプロセッサを識別します。 モデルは、プロセッサフ​​ァミリの1つのインスタンスを指定します。 ステッピングは、特定のモデルの特定のバージョンを識別します。したがって、ファミリ、モデル、ステッピングは一緒になって、プロセッサの固有の識別または署名を形成します。

ファミリの番号がかなり乱雑であるため、製造元に問い合わせると最も役に立ちますが、ありがたいことに、ファミリー番号が16（16進数では10）がAMD （ "AuthenticAMD"という製造元の文字列を持つ必要があります）。具体的にはバルセロナのマイクロアーキテクチャであるAMD K10です。つまり、HyperThreadingはありません。これはネイティブのクアッドコアシステムに過ぎません。

モデルを見ることでさらに絞り込むことができます。 Athlon II、Opteron、Phenom、Phenom II、Sempron、Turion、V-Seriesなど、さまざまなブランドのバルセロナコアをベースにしたさまざまなモデルがありました。あなたのものはモデル4です。これは、さまざまなCPUのモデル番号とステッピングを示す良いリソースがわからないため、扱いにくいところです。あなたはメーカーに直接行く必要があり、そのマニュアルを歩きます。たとえば、here is AMD's Revision Guide for the 10h Familyとなります。 「プロセッサ識別」セクション（PDFにブックマークとして表示されます）に行くと、有望に見えるものが表示されますが、情報は簡単に消化可能な形では表示されません。 Family（8-11）、Model（4-7）、およびStepping（0-3）に対応する個々のビットを抽出する必要がある長い16進値が得られます。

AMD Phenom II X4であることは間違いありません。 X4はクアッドコアに合っており、厄介な一見から、Phenom IIはモデル4であるように見えます。

とにかく、マイクロアーキテクチャが知っておく必要があるすべてをあなたに伝えているので、しばらく前に停止している可能性があります。これはAMDバルセロナのコアで、Supplemental SSE3 (SSSE3)の指示（3つの Sの - SSE3と混同しないでください;命名規則はばかげています）をサポートしていません。 SSSE3は、Core 2マイクロアーキテクチャとともにリリースされたIntelによって考案されました。

AMDはBobcat/Bulldozerまで実装していませんでした。 Bulldozerは、デスクトップとサーバー用の次世代ファミリー21（15h）でしたが、BobcatはAMDのAPUの低ポアコアでした。

SSSE3は実際には多くの新しい命令を提供していませんでした。主にパックド整数を扱うことを目的としたものであり、そのほとんどはaren't very excitingです。ダンプはにも、クラッシュの原因となった命令のオペコードが表示されます。そうでない場合は、コードのバイトアドレスから戻って調べなければなりません。これは、どの命令が問題であるかを正確に伝えます。私はPSHUFBを使用して実際にかなり役に立つSSSE3命令であるバイトをシャッフルすることを推測しています。私が見た1つの共通の使用はa fast population count algorithmです（SSSE3を必要としない他の実装もありますが、高速ではないにしてもほとんど同じです）。

あなたがMSVCでコンパイルしていると仮定すると、私は実際にはこの命令を出すのに驚いています。それを得るには、AVXをターゲットにするようにコンパイラに指示する必要があります。これにより、Sandy Bridge/Bulldozerより古いものでコードが実行されなくなります。私はあなたが最小限のシステム要件を満たすことを望まないならば、同じことをするための別の手順を理解することができます。 pshufd、またはmovaps + shufpsが考えられます。

Answer 2

コマンド!sysinfo、!cpuinfoと!errecはkdexts拡張で定義されたカーネルダンプ・コマンドですので、彼らは、ユーザーモードのデバッグでは使用できませんし、おそらくあなたが明示的にその拡張子をロードする場合はうまく動作しません。

Stream 7: type SystemInfoStream (7), size 00000038, RVA 000000BC 
    ProcessorArchitecture 0000 (PROCESSOR_ARCHITECTURE_INTEL) 
    ProcessorLevel   0006 
    ProcessorRevision  2A07 
    NumberOfProcessors  04 
    ... (OS specifics) ... 

残念ながら、それは正確に!cpuidで表示されるのと同じですので、あります：

だけのアイデアは、私が持っていたダンプからより多くの情報を得るためには、出力ストリームはこのようになりますSystemInfoStreamと呼びます.dumpdebugました実際にダンプに含まれる情報はこれ以上ありません。