>
![MC910216362[1] MC910216362[1]](https://i1.wp.com/lh5.ggpht.com/-OU-9tvzdVkc/Tf8qviG3SXI/AAAAAAAAAtg/_iKCDEcWGQU/MC91021636214.png)
2) Потом воспроизводим проблему. Я запустил свой chrome (слишком много вкладок открыто в IE ;) ) и сходил на сайт www.microsoft.com.
3) Останавливаем:
netsh trace stop
Обратите внимание, что трассировка создала два файла: .etl and .cab. ETL это как раз тот, в котором записаны наши пакетики. Второй… Это то, что даже добавляет “чудесности” этому методу, но мы обсудим его в следующей статье.
4) Открываем наш файл на любом компьютере с помощью Network Monitor:
Ой… Что это с нашими парсерами? Если взглянуть поближе, то мы увидим следующее:
Process: Windows stub parser: Requires full Common parsers. See the «How Do I Change Parser Set Options(Version 3.3 or before) or Configure Parser Profile (Version 3.4)» help topic for tips on loading these parser sets.
Что ж, очевидно, некоторые парсеры не подключены. Давайте это сделаем, благо, это легко (да, я использую NetMon 3.4). Идем в tools->options
Смотрим на вкладку Parser Profiles:
И включаем профиль Windows нажав на нем правой кнопкой и кликнув опцию Set As Active:
И вот теперь все кристально ясно:
5) Ну итеперь делаем все, что нам нужно с помощью NetMon, например, посмотрим на DNS-запрос от имени Chrome:
Ну не здорово ли? Точно здорово, потому что мы еще не смотрели на .cab-файл, который содержит тонны полезной информации… Но для этого я отвел следующую статью.
>"Это можно сделать с помощью встроенной утилиты, а именно netmon" netsh, наверное
НравитсяНравится
>Спасибо большое! Поправил.
НравитсяНравится
>Хочу еще ссылкой поделиться http://blogs.technet.com/b/nettracer/archive/2010/08/02/have-you-ever-wanted-to-see-which-windows-process-sends-a-certain-packet-out-to-network.aspxЧетвертый способ тоже интересный.
НравитсяНравится
>Спасибо, принято =)
НравитсяНравится