Узнать модель процессора по аварийному дампу в пользовательском режиме

У меня есть аварийный дамп для моего приложения. Мое приложение не работает, когда какой-то пользователь говорит "недопустимая инструкция", пытаясь выполнить какую-то инструкцию SSSE, которая у меня есть.

В WinDBG, как мне узнать модель процессора, чтобы я мог узнать его набор инструкций и либо поддержать набор инструкций, либо обновить минимальные аппаратные требования приложения?

Вот вывод !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) напечатать "Экспорт не найден".

Источник

2 ответа

Решение

Вы определенно не получаете много информации здесь. Хотя в дампах обычно нет всей необработанной информации о процессоре, вы должны по крайней мере увидеть строку производителя. О, хорошо, давайте посмотрим на то, с чем вы должны работать здесь...

CP В столбце указан логический номер процессора, поэтому вы знаете, что имеете дело с системой, в которой есть 4 логических процессора. Может быть четырехъядерный или двухъядерный с HyperThreading.

F/M/S Семейство / Модель / Степпинг, которые являются распространенным и довольно стандартным способом идентификации процессоров. Как говорит AMD:

Семейство процессоров идентифицирует один или несколько процессоров как принадлежащих к группе, которая обладает некоторым общим определением для программных или аппаратных целей. Модель определяет один экземпляр семейства процессоров. Степпинг идентифицирует конкретную версию конкретной модели. Следовательно, Family, Model и Stepping, взятые вместе, образуют уникальную идентификацию или подпись для процессора.

Это очень полезно, если у вас есть производитель, когда вы ищете эти вещи, потому что номера семейств довольно запутанные, но, к счастью, совершенно ясно, что номер семейства 16 (10 в шестнадцатеричном) соответствует процессору AMD (который должен иметь производитель строки "AuthenticAMD"). В частности, это AMD K10, которая является барселонской микроархитектурой. Это означает, что нет HyperThreading - это просто родная четырехъядерная система.

Мы можем сузить это дальше, посмотрев на модель. Было много разных моделей, основанных на ядре Barcelona, ​​под разными названиями Athlon II, Opteron, Phenom, Phenom II, Sempron, Turion и V-Series. У вас модель 4. Это где-то сложно, потому что я не знаю хорошего ресурса, который перечисляет номера моделей и степпинги для различных процессоров. Вы должны пойти непосредственно к производителю и просмотреть их руководства. Например, вот руководство по пересмотру AMD для семейства 10h. Если вы перейдете в раздел "Идентификация процессора" (для меня он отображается в виде закладки в PDF), вы увидите что-то многообещающее, но информация, безусловно, не представлена ​​в легко усваиваемой форме. Вы получаете длинные шестнадцатеричные значения, из которых вы должны извлечь отдельные биты, соответствующие семейству (8-11), модели (4-7) и пошаговому (0-3).

Я не делал всю тяжелую работу, чтобы быть уверенным, я просто догадываюсь, что это AMD Phenom II X4. X4 подходит для четырехъядерного процессора, и из беглого взгляда видно, что Phenom II - это модель 4.

В любом случае, вы, возможно, могли бы остановиться на некоторое время назад, потому что микроархитектура рассказывает вам все, что вам нужно знать. Это ядро ​​AMD Barcelona, ​​которое не поддерживает дополнительные инструкции SSE3 (SSSE3) (три буквы S - не путать с SSE3; соглашения об именах смешны). SSSE3 был изобретен Intel, выпущен с микроархитектурой Core 2.

AMD не реализовала их до Bobcat/Bulldozer. Бульдозер был последующим поколением, семейство 21 (15 часов), для настольных компьютеров и серверов, в то время как Bobcat был низкопористыми ядрами для APU AMD.

SSSE3 действительно не предлагал так много новых инструкций. Всего 16, в основном предназначенных для работы с упакованными целыми числами, и большинство из них не очень увлекательны. В дампе также должен быть указан код операции, вызвавший сбой. Если нет, вам придется вернуться и выяснить это по байтовому адресу кода. Это скажет вам точно, какая инструкция является проблемой. Я предполагаю, что вы используете PSHUFB для перетасовки байтов на месте, что является единственной инструкцией SSSE3, которая на самом деле довольно полезна. Одно из распространенных применений, которое я видел, - это алгоритм быстрого подсчета населения (хотя есть и другие реализации, для которых не требуется SSSE3, которые почти одинаково быстры, если не быстрее).

Предполагая, что вы компилируете с MSVC, я на самом деле немного удивлен, увидев, что он испускает эту инструкцию. Чтобы получить его, вы должны указать компилятору нацеливаться на AVX, что помешает вашему коду работать на чем-то более старом, чем Sandy Bridge/Bulldozer. Я уверен, что если вы не хотите увеличивать свои минимальные системные требования, вы можете найти альтернативную последовательность инструкций, чтобы сделать то же самое. pshufd, или же movaps + shufps Возможные кандидаты на обходные пути.

Источник

Команды !sysinfo, !cpuinfo а также !errec являются командами дампа ядра, определенными в расширении kdexts, поэтому они недоступны при отладке в пользовательском режиме и, вероятно, не будут работать, если вы явно загрузите это расширение.

Единственная идея, чтобы получить больше информации от свалки, которую я имел, была .dumpdebug который выведет поток под названием SystemInfoStream это выглядит так:

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

К сожалению, это точно так же, как отображается !cpuidтак что на самом деле больше нет информации, содержащейся в дампе.

Источник
Другие вопросы по тегам