Как узнать какие dll использует программа
1) Можно ли сделать так, чтобы при компиляции весь код из таких библиотек компилировался в основную прогу, т.е. чтобы эти длл-ки не требовались
2) Если нет, то как узнать, какие библиотеки может потребовать прога, чтобы распространять их вместе с прогой?
← →Игорь Шевченко © ( 2009-04-21 18:14 ) [1]
> Если нет, то как узнать, какие библиотеки может потребовать
> прога, чтобы распространять их вместе с прогой?
tdump имя-проги
← →12 © ( 2009-04-22 10:33 ) [2]
Function GetAllProcesses2: Boolean;
Type
TEnumProcessModules = Function (hProcess: THandle; lphModule: LPDWORD; cb: DWORD; Var lpcbNeeded: DWORD): BOOL Stdcall;
TGetModuleFileNameExA = Function (hProcess: THandle; HMODULE: HMODULE; lpFileName: PAnsiChar; nSize: DWORD): DWORD Stdcall;
Var
EnumProcessModules : TEnumProcessModules;
GetModuleFileNameExA: TGetModuleFileNameExA;
hPSAPI : THandle;
Counter1 : LongWord;
pbNeeded : DWORD;
ModHndls : Array[0..1023] Of DWORD;
mbNeeded : DWORD;
ModulePath : String;
Begin
Result := False;
hPSAPI := LoadLibrary("PSAPI.dll");
If hPSAPI < 32 Then
Begin
Result := False;
Exit;
End;
EnumProcessModules := GetProcAddress(hPSAPI, "EnumProcessModules");
GetModuleFileNameExA := GetProcAddress(hPSAPI, "GetModuleFileNameExA");
If EnumProcessModules(GetCurrentProcess, @ModHndls, Length(ModHndls), mbNeeded)
Then For Counter1 := 0 To (mbNeeded Div 4) - 1 Do
Begin
SetLength(ModulePath, MAX_PATH);
GetModuleFileNameExA(GetCurrentProcess, ModHndls[Counter1], PChar(ModulePath), MAX_PATH);
Form1.memo1.Lines.add(ModulePath);
end;
FreeLibrary(hPSAPI);
End;
Попробую прогу от Rouse.
← →Юрий Зотов © ( 2009-04-22 14:01 ) [5]
Запускаем программу под средой, приходим на BreakPoint, лезем в меню View - и где-то там видим пункт, который показывает список статически загруженных DLL. А загружаемые ручками мы и так знаем.
← →Anatoly Podgoretsky © ( 2009-04-22 14:13 ) [6]
> Franzy (22.04.2009 13:51:04) [4]
Данная задача решения не имеет.
← →Игорь Шевченко © ( 2009-04-22 21:48 ) [7]
> Написал прогу, на моем компе нормально работает, принес
> на комп, где дельфи нет и никогда не стояло
> НЕТ той длл, на отсутствие которой ругалась ось (dforrt.
> dll).
эта DLL к Delphi не относится
← →Franzy ( 2009-04-23 12:35 ) [8]
Есть подозрение, что используемая длл тоже какие-то свои длл использует.
← →Franzy ( 2009-04-23 13:38 ) [9]
Да, так и есть. tdump длл-ки показал, что она обращается к этой самой dforrt.dll. А еще к какой-то MSVCRT.dll:
IMPORT: MSVCRT.dll=."malloc"
IMPORT: MSVCRT.dll=."_adjust_fdiv"
IMPORT: MSVCRT.dll=."_initterm"
IMPORT: MSVCRT.dll=."free"
Это родная виндовская или тоже какая-то левая?
Сергей М. © ( 2009-04-23 13:43 ) [10]
> Это родная виндовская или тоже какая-то левая?
MicroSoft VisualC Run-Time library
← →Сергей М. © ( 2009-04-23 13:45 ) [11]
Родство с этим модулем у "винды" того же колена, что и родство Делфи-приложений с можулем rtlXX.bpl
← →Franzy ( 2009-04-23 14:02 ) [12]
Так она родная для винды или нет? Или тоже из вижл студио?
← →Сергей М. © ( 2009-04-23 14:46 ) [13]
она родная не для винды, а для тех ее компонентов, которые разрабатывались с использованием MSVC (VC - это не VisualStudio, а VisualC)
← →Anatoly Podgoretsky © ( 2009-04-23 15:05 ) [14]
> Franzy (23.04.2009 13:38:09) [9]
Левая - MicroSoft VC RunTime
← →DVM © ( 2009-04-23 15:07 ) [15]
Dependency Walker
← →Franzy ( 2009-04-23 15:17 ) [16]
Т.е. она есть не везде и ее тоже надо включать вместе с dforrt.dll в комплект с экзишником?
← →Сергей М. © ( 2009-04-23 15:22 ) [17]
Не надо.
Модуль поставляется штатно в составе дистрибутива, без него невозможна работа огромной кучи штатно поставляемого в составе ОС прикладного софта.
DVM © ( 2009-04-23 15:29 ) [18]
> Сергей М. © (23.04.09 15:22) [17]
>
> Не надо.
Не факт кстати. Плюс у нее версии разные еще есть.
> Franzy (23.04.09 15:17) [16]
>
> Т.е. она есть не везде и ее тоже надо включать вместе с
> dforrt.dll в комплект с экзишником?
Если нужна MSVCRT.dll, то разумнее в процессе установки программы поставить еще м Microsoft Visual C++ 2008 Redistributable, ну или другой версии.
Игорь Шевченко © ( 2009-04-23 18:46 ) [19]
> Это родная виндовская или тоже какая-то левая?
иногда, когда я делаю небольшой проект, я недостаточно осторожен и случайно добавляю зависимость для DLL, о которой я не знаю. Когда я отправляю эту программу другу или другим людям, "это не работает", потому что "некоторая DLL" отсутствует. Это, конечно, потому, что программа может найти DLL в моей системе, но не в их.
есть ли программа / скрипт, который может сканировать исполняемый файл для зависимостей DLL или выполнять программу в "чистой" среде без DLL для тестирования предотвратить эти упс ситуациях?
dumpbin из Visual Studio tools (папка VC\bin) может помочь здесь:
Я могу порекомендовать интересное решение для поклонников Linux. После того, как я изучил это решение, я переключился с DependencyWalker на это.
вы можете использовать ваш любимый ldd через связанные с Windows exe , dll .
для этого Вам необходимо установить Cygwin (базовая установка, без дополнительных пакетов не требуется) на вашем Windows, а затем просто запустите Cygwin Terminal . Теперь вы можете запускать свои любимые команды Linux, в том числе:
UPD: можно использовать ldd и через Git Bash терминал на Windows. Нет необходимости устанавливать cygwin в случае, если у вас уже установлен git.
- существует программа под названием "зависит"
- Если у вас установлен cygwin, ничего проще, чем файл ldd.exe
безопаснее всего иметь чистую виртуальную машину, на которой вы можете протестировать свою программу. В каждой версии, которую вы хотите протестировать, восстановите VM до его начального чистого значения. Затем установите программу с помощью ее установки и посмотрите, работает ли она.
Dll проблемы имеют разные лица. Если вы используете Visual Studio и динамически подключаетесь к CRT, вы должны распространять библиотеки CRT. Обновите VS, и вы должны распространить другую версию CRT. Просто проверка зависимостей не достаточно, так как вы можете пропустить их. Выполнение полной установки на чистой машине является единственным безопасным решением, IMO.
Если вы не хотите устанавливать полномасштабную тестовую среду и иметь Windows 7, Вы можете использовать XP-Mode в качестве начальной чистой машины и XP-более дублировать ВМ.
на вашей машине разработки вы можете выполнить программу и запустить Sysinternals Process Explorer. В нижней панели он покажет вам загруженные библиотеки DLL и текущие пути к ним, что удобно по ряду причин. Если вы выполняете свой пакет развертывания, он покажет, на какие DLL ссылаются в неправильном пути (т. е. не были упакованы правильно).
предупреждение: Я испортил свои окна в прошлом, дурачась с gflag, заставляя его ползать на колени, вы были предупреждены.
Примечание: "Loader snap" для каждого процесса, поэтому UI enable не будет оставаться проверенным (используйте cdb или glfags-i)
пожалуйста, поиск "зависит.exe " в google это крошечная утилита для обработки этого.
Если у вас есть исходный код, вы можете использовать ndepend.
Это дорого и делает намного больше, чем анализ зависимостей, поэтому это может быть излишним для того, что вы ищете.
есть ли программа/скрипт, который может сканировать исполняемый файл для DLL зависимости или выполнение программы в "чистой" среде без DLL для тестирования, чтобы предотвратить эти ситуации oops?
на панели свойств проекта NDepend можно определить, какие сборки приложений следует анализировать (зеленым цветом) и NDepend сделает вывод Сборки сторонних производителей, используемые приложениями (в синем). Список каталогов, в которых выполняется поиск приложений и сторонних сборок.
В этой статье мы рассмотрим концепцию перехвата порядка поиска динамически подключаемых библиотек (DLL hijacking) и то, как она может быть использована для достижения устойчивости (persistence) в юзерленде в системах Windows. Этот метод описан в MITER ATT&CK в разделе: «Перехват порядка поиска DLL (T1038)».
Подмена DLL может быть использована злоумышленниками для множества разных целей, но в этой статье основное внимание будет уделено достижению устойчивости с помощью приложений с автозапуском. Например, поскольку Slack и Microsoft Teams запускаются при загрузке (по умолчанию), подмена DLL в одном из этих приложений позволит злоумышленнику получить устойчивый доступ к своей цели — всякий раз, когда пользователь входит в систему.
После представления концепции DLL, порядка поиска DLL, и подмены DLL, я раскрою процесс автоматизации обнаружения возможности перехвата DLL. В этой статье будет рассказано об обнаружении путей перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Наконец, я обнаружил несколько путей перехвата DLL, которые использовались разными приложениями, исследовал основную причину и обнаружил, что приложения, использующие определенные вызовы API Windows, подвержены перехвату DLL, когда не работают из C:\Windows\System32\ .
Я хочу поблагодарить своего коллегу Джозайю Массари ( @Airzero24 ) за то, что он первым обнаружил некоторые из этих перехватов DLL, объяснил их методологию и вдохновил меня автоматизировать обнаружение.
Что такое DLL?
DLL — это библиотека, содержащая код и данные, которые могут использоваться одновременно более чем одной программой. (Сурс)
Функциональные возможности DLL могут быть использованы приложением Windows с помощью одной из функций LoadLibrary* . Приложения могут ссылаться на DLL, разработанные специально для этих приложений, или DLL Windows, уже находящиеся на диске в System32. Разработчики могут загружать DLL из System32, чтобы использовать в своих приложениях функционал, уже реализованный в Windows, без необходимости писать этот функционал с нуля.
Порядок поиска DLL и перехват
Поскольку DLL существуют в виде файлов на диске, вы можете задаться вопросом, как приложение узнает, откуда загружать DLL? Microsoft подробно задокументировала порядок поиска DLL здесь.
Начиная с Windows XP SP2, безопасный режим поиска DLL включен по умолчанию ( HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode ). При включенном безопасном режиме порядок поиска DLL следующий:
- Каталог, из которого загружено приложение.
- Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
- 16-битный системный каталог. Функции, которая предоставляет путь к этому каталогу, нет, но в нем происходит поиск.
- Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
- Текущий каталог.
- Каталоги, перечисленные в переменной среды PATH. Обратите внимание, что сюда не входят пути для каждого приложения, указанные в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.
Если приложение не указывает, откуда загружать DLL, Windows использует порядок поиска DLL по умолчанию, приведенный выше. Первая позиция в порядке поиска DLL (каталог, из которого загружается приложение) представляет интерес для злоумышленников.
Если разработчик приложения предполагает загрузку DLL из C:\Windows\System32 , но явно не прописал это в приложении, вредоносная DLL, помещенная в каталог приложения, будет загружена раньше, чем легитимная DLL из System32. Загрузка вредоносной DLL называется подменой (или перехватом) DLL и используется злоумышленниками для загрузки вредоносного кода в доверенные/подписанные приложения.
Использование подмены DLL для достижения устойчивости
Подмена DLL может использоваться для достижения устойчивости, когда уязвимое приложение/служба запускается и вредоносная DLL размещается в уязвимом месте. Мой коллега, @Airzero24 , обнаружил подмену DLL в Microsoft OneDrive, Microsoft Teams и Slack в виде userenv.dll .
Именно эти программы стали целью перехвата, потому что по умолчанию они настроены на запуск при загрузке Windows. Это можно увидеть ниже в диспетчере задач:
Приложения Windows, настроенные на автозапуск
Чтобы проверить подмену DLL, я создал загрузчик шеллкода DLL, который запускал Cobalt Strike Beacon. Я переименовал вредоносную DLL в userenv.dll и скопировал ее в каталог уязвимого приложения. Я запустил приложение и увидел свой новый Beacon коллбек.
Cobalt Strike Beacon через перехват DLL
Используя Process Explorer, я могу проверить, действительно ли моя вредоносная DLL была загружена уязвимым приложением.
Обозреватель процессов, показывающий загруженную вредоносную DLL
Автоматическое обнаружение возможности перехвата DLL
После подтверждения ранее известного перехвата DLL, я хотел проверить, смогу ли я найти другие возможности для подмены DLL, которые можно было бы эксплуатировать.
Код, использованный в моих проверка, можно найти здесь.
На примере Slack
Чтобы начать этот процесс, я запустил Process Monitor (ProcMon) со следующими фильтрами:
Затем я запустил Slack и изучил ProcMon на предмет любых DLL, которые Slack искал, но не смог найти.
Возможные пути перехвата DLL, обнаруженные с помощью ProcMon
Я экспортировал эти данные из ProcMon в виде CSV файла для облегчения парсинга в PowerShell.
С моей текущей DLL загрузчика шелл-кода я не смог бы легко определить имена DLL, которые были успешно загружены Slack. Я создал новую DLL, которая использовала GetModuleHandleEx и GetModuleFileName для определения имени загруженной DLL и записи его в текстовый файл.
Моя следующая цель состояла в том, чтобы проанализировать CSV-файл на наличие в списке путей к DLL, просмотреть этот список, скопировать мою тестовую DLL по указанному пути, запустить целевой процесс, остановить целевой процесс и удалить тестовую DLL. Если тестовая DLL была успешно загружена, она запишет свое имя в результирующий файл.
Когда этот процесс завершится, у меня будет список возможных перехватов DLL (я надеюсь), записанных в текстовый файл.
Всю магию в моем проекте DLLHijackTest творит скрипт PowerShell. Он принимает путь к CSV-файлу, сгенерированному ProcMon, путь к вашей вредоносной DLL, путь к процессу, который вы хотите запустить, и любые аргументы, которые вы хотите передать процессу.
Параметры Get-PotentialDLLHijack
Get-PotentialDLLHijack.ps1
Через несколько минут я проверяю текстовый файл, указанный в моей «вредоносной» DLL, на предмет возможных перехватов DLL. Я обнаружил следующие возможные пути перехвата для Slack:
На примере Microsoft Teams
Выполняем описанный выше процесс еще раз:
- Используйте ProcMon для выявления потенциальных путей перехвата DLL, экспортируйте эти данные в виде CSV файла.
- Определите путь запуска процесса.
- Определите любые аргументы, которые вы хотите передать процессу.
- Запустите Get-PotentialDLLHijack.ps1 с соответствующими аргументами.
Примечание: Мне пришлось внести небольшие изменения в скрипт PowerShell, чтобы завершить Teams.exe , так как мой скрипт пытается завершить процесс, который он пытался запустить, в данном случае это Update.exe .
На примере Visual Studio Code
Повторяя описанный выше процесс, я обнаружил следующие потенциальные пути перехвата для Visual Studio Code:
Подмена общих (shared) DLL
Я заметил, что Slack, Microsoft Teams и Visual Studio Code совместно используют следующие DLL:
- WINSTA.dll
- LINKINFO.dll
- ntshrui.dll
- srvcli.dll
- cscapi.dll
Методология: понимание путей перехвата общих DLL
Я следил за стек трейсом, когда Slack пытался загрузить WINSTA.dll , LINKINFO.dll , ntshrui.dll , srvcli.dll и cscapi.dll .
DLL с отложенной загрузкой
Я заметил сходство в стек трейсе при загрузке WINSTA.dll , LINKINFO.dll , ntshrui.dll и srvcli.dll .
Стек трейс, когда Code.exe пытается загрузить WINSTA.dll
Стек трейс, когда Teams.exe пытается загрузить LINKINFO.dll ,
Стек трейс, когда Slack пытается загрузить ntshrui.dll
Стек трейс постоянно содержит вызов _tailMerge_< dllname>_dll , delayLoadHelper2 за которым следует LdrResolveDelayLoadedAPI . Такое поведение было одинаковым для всех трех приложений.
Я определил, что это поведение связано с отложенной загрузкой DLL. Из стек трейса при загрузке WINSTA.dll я мог видеть, что модулем, ответственным за эту отложенную загрузку, был wtsapi32.dll .
Я открыл wtsapi32.dll в Ghidra и использовал Search -> For Strings -> Filter: WINSTA.dll . Двойной клик по найденной строке приведет вас к ее локации в памяти.
Строка « WINSTA.dll » в wtsapi32.dll
Кликнув правой кнопкой мыши по локации в памяти, мы сможем найти любые ссылки на этот адрес.
Ссылки на WINSTA.dll
Следуя ссылкам, мы видим, что строка WINSTA.dll передается в структуру с именем ImgDelayDescr . Глядя на документацию по этой структуре, мы можем подтвердить, что она связана с отложенной загрузкой DLL.
Эту структуру можно передать в __delayLoadHelper2 , который будет использовать LoadLibrary / GetProcAddress для загрузки указанной DLL и исправления адреса импортируемой функции в таблице адресов импорта отложенной загрузки (IAT).
Найдя другие ссылки на нашу структуру ImgDelayDescr , мы можем найти вызов __delayLoadHelper2 , который затем вызывает ResolveDelayLoadedAPI . Я переименовал имя функции, типы и переменные, чтобы облегчить понимание.
__delayLoadHelper2 и ResolveDelayLoadedAPI в Ghidra
Отлично! Это соответствует тому, что мы видели в нашем ProcMon стек трейсе, когда Slack пытался загрузить WINSTA.dll .
__delayLoadHelper2 и ResolveDelayLoadedAPI в ProcMon.
Такое поведение было единообразно для WINSTA.dll , LINKINFO.dll , ntshrui.dll и srvcli.dll . Основным отличием каждой DLL с отложенной загрузкой была «родительская» DLL. Во всех трех приложениях:
- wtsapi32.dll отложено загружала WINSTA.dll
- shell32.dll отложенно загружала LINKINFO.dll
- LINKINFO.dll отложено загружала ntshrui.dll
- ntshrui.dll отложено загружала srvcli.dll
Подмена DLL в NetShareGetInfo и NetShareEnum
Я следил за стек трейсом, когда Slack пытался загрузить cscapi.dll и видел вызов LoadLibraryExW , который, по-видимому, исходил из srvcli.dll .
Стек трейс при загрузке cscapi.dll
Я открыл srvcli.dll в Ghidra и использовал Search -> For Strings -> Filter: cscapi.dll . Двойной клик по найденной строке и переход по ссылкам приводит к ожидаемому LoadLibrary вызову.
srvcli.dll вызывает LoadLibrary для cscapi.dll
Переименовав функцию, содержащую вызов LoadLibrary , и проследовав по ссылкам, я получил два места использования функции:
NetShareGetInfo загружает cscapi.dll
Я проверил это с помощью РоС программ, которые вызывали NetShareEnum и NetShareGetInfo :
NetShareEnum.exe загружает cscapi.dll
NetShareGetInfo.exe загружает cscapi.dll
Результаты
В Slack доступны следующие пути подмены DLL:
В Microsoft Teams доступны следующие пути подмены DLL:
В Visual Studio Code доступны следующие пути подмены DLL:
Кроме того, я обнаружил, что программы, использующие NetShareEnum и NetShareGetInfo , предоставляют возможность подмены DLL в форме cscapi.dll из-за жестко захардкоженного вызова LoadLibrary . Я подтвердил это поведение с помощью Ghidra и PoC.
Заключение
Напомним, что перехват DLL — это метод, с помощью которого злоумышленники могут повлиять на выполнение кода в подписанных/доверенных приложениях. Я создал инструменты, помогающие автоматизировать обнаружение путей перехвата DLL. Используя этот инструмент, я обнаружил пути перехвата DLL в Slack, Microsoft Teams и Visual Studio Code.
Я заметил, что пути перехвата DLL этих трех приложений частично совпадают, и исследовал причину. Я осветил свою методику понимания данного совпадения. Я узнал о DLL с отложенной загрузкой и обнаружил два вызова API, которые делают возможным перехват DLL в любой программе, которая их вызывает:
- NetShareEnum загружает cscapi.dll
- NetShareGetInfo загружает cscapi.dll
Ссылки
В процессе отладки в Visual Studio окно Модули отображает список используемых приложением библиотек DLL и исполняемых файлов ( .exe), а также сведения о них.
Окно "Модули" недоступно при отладке SQL и скриптов.
Использование окна модулей
Чтобы открыть окно "Модули" во время отладки, выберите Отладка > Окна > Модули или нажмите клавиши CTRL+ALT+U.
По умолчанию модули в окне Модули упорядочены в порядке загрузки. Чтобы выполнить сортировку по любому столбцу окна, щелкните заголовок соответствующего столбца.
Загрузить символы
В столбце Состояние символов в окне Модули показано, для каких модулей загружены отладочные символы. Если здесь указано состояние Загрузка символов пропущена, Невозможно найти или открыть PDB-файл или Загрузка отключена параметром включения и исключения, вы можете загрузить символы вручную. Дополнительные сведения о загрузке и использовании символов см. в статье Указание файлов символов (.pdb) и исходных файлов.
Загрузка символов вручную
В окне Модули щелкните правой кнопкой модуль, для которого не загружены символы.
Выберите Сведения о загрузке символов, чтобы узнать, почему символы не были загружены.
Щелкните Загрузить символы, чтобы загрузить символы вручную.
Если символы не загружаются, выберите Параметры символов, чтобы открыть диалоговое окно Параметры и указать или изменить расположение для загрузки символов.
Вы можете скачать символы с общедоступных серверов символов Майкрософт или других аналогичных серверов, а также загрузить их из локальной папки на компьютере. Дополнительные сведения см. в разделе Настройка расположения файлов символов и поведения при загрузке.
Изменение параметров поведения при загрузке символов
В окне Модули щелкните правой кнопкой мыши любой модуль.
Выберите Параметры символов.
Выберите Загрузить все символы или выберите конкретные модули.
Изменение поведения загрузки символов для конкретного модуля
В окне Модули щелкните правой кнопкой мыши требуемый модуль.
В контекстном меню установите или снимите флажок Всегда загружать автоматически. Изменения вступят в силу при следующем сеансе отладки.
Введение
Когда-нибудь интересует, какая программа открывает определенный файл или каталог? Теперь вы можете узнать. В обозревателе процессов отображаются сведения о том, какие дескрипторы и процессы DLL были открыты или загружены.
В обозревателе процессов отображается два дочерних окна. В верхнем окне всегда отображается список текущих активных процессов, включая имена их учетных записей-владельцев, а информация, отображаемая в нижнем окне, зависит от режима, в котором находится Обозреватель процессов . Если он находится в режиме обработки, вы увидите дескрипторы, которые процесс, выбранный в верхнем окне, открылся; Если Обозреватель процессов находится в режиме DLL, вы увидите библиотеки DLL и файлы, отображенные в памяти, загруженные процессом. В обозревателе процессов также имеется мощная функция поиска, которая быстро показывает, какие процессы имеют открытые дескрипторы, или загружены библиотеки DLL.
уникальные возможности обозревателя процессов позволяют отслеживать проблемы с версиями библиотек DLL или утечки, а также предоставлять сведения о том, как Windows и приложения работают.
Связанные ссылки
-
с официальными обновлениями и сведениями о выявленных погрешностях по Windows внутренним, помечайте russinovich) и дэвид соломоновы. в официальное руководство по программам sysinternals utilities, марк russinovich) и аарон margosis), включая описания всех средств, их функции, способы их использования для устранения неполадок, а также примеры реальных случаев их использования.
Выполняется в:
- клиент: Windows 8.1 и выше.
- сервер: Windows Server 2012 и более поздних версий.
Установка
Просто запустите Обозреватель процессов (procexp.exe).
Файл справки описывает операции и использование обозревателя процессов . Если у вас возникли проблемы или вопросы, обратитесь к разделу Process Explorer в Microsoft Q & A.
Примечание об использовании символов
Если путь настроен на DBGHELP.DLL и путь к символам использует сервер символов, расположение DBGHELP.DLL также должно содержать SYMSRV.DLL, поддерживающих используемые пути к серверу. См. документацию по SymSrv или дополнительные сведения об использовании серверов символов.
Подробнее
Ниже приведены некоторые другие средства просмотра и сведения о библиотеках DLL, доступные в Sysinternals:
Читайте также: