Tdi driver что это

Обновлено: 10.01.2025

Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI).

Изначально этот интерфейс планировалось использовать в пользовательском режиме работы ОС. В окончательном варианте интерфейс стал работать в режиме ядра, однако все еще может быть использован напрямую из пользовательского уровня. TDI предоставляется верхней частью любого транспортного стека протоколов Windows NT. TDI обеспечивает независимость TDI-клиентов от используемых ими транспортов. TDI поддерживает передачу как с установлением постоянного сеанса (виртуальная цепь), так и без него (датаграммы).

Требование, чтобы все драйверы транспорта предоставляли единый общий интерфейс TDI, облегчает задачу их разработки, а также разработки TDI-клиентов, потому что только этот интерфейс необходимо запрограммировать.

Так как TDI является относительно новым сетевым интерфейсом, и большинство приложений разработаны для использования других существующих стандартных интерфейсов, таких как NetBIOS и WinSockets, то Windows NT включает эмуляторы для этих двух популярных интерфейсов. Части уровня ядра этих эмуляторов, являющиеся драйверами файловых систем, отображают родные функции с соответствующими параметрами в одну или несколько TDI-функций, а затем вызывают соответствующие драйверы транспортов через TDI.

Интерфейс TDI включает следующее:

Множество стандартных диспетчерских точек входа, обеспечиваемых транспортным драйвером, к которому TDI-клиент может обратиться с запросом ввода/вывода.
Множество процедур обратного вызова, экспортируемых любым TDI-клиентом и регистрируемых транспортным драйвером, для получения TDI-клиентом уведомления о произошедшем сетевом событии.
Параметры, структуры, lOCTLs и правила, ассоциированные с процедурами транспорта и его клиента.
Множество функций вида TdiXxx, которые транспорт и его клиент могут вызывать для взаимодействия друг с другом.
Множество макросов и функций вида TdiBuildXxx, которые TDI-клиент может использовать, чтобы обеспечить принятие запросов нижележащим транспортом.

Программная модель TDI очень похожа на модель Winsocket. TDI-клиенты реализуют следующие шаги для установления соединения с удаленным сервером:

Краткий обзор драйверов спецификации NDIS

Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:

Минипорт-драйверы (драйверы адаптера)
Промежуточные драйверы (например, psched.sys)
Драйверы протокола (например, tcpip.sys)

Минипорт-драйверы

производит инициализацию своего устройства (адаптера)
создание /включение/выключение/удаление сетевых подключений
выдача клиенту или изменение параметров адаптера
отправка пакетов
получение пакетов
оповещение ОС о состоянии адаптера
перезагрузка и остановка адаптера

Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).

Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.

Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.

LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера

Промежуточные драйверы

Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.

организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
фильтруют и перехватывают трафик
маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)

Драйверы протоколов

Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.

К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).

Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).

ОС Windows: сетевая подсистема

Изучить сетевую подсистему этой ОС так же просто, как в ОС Linux, не получится. Самый большой камень преткновения - закрытый исходный код. Однако давайте попытаемся восстановить информацию о том, как работает сетевая подсистема в рамках этой ОС. В качестве целей будем использовать то, что нашли в Linux:

Где располагается код для создания и работы с сокетами;

Какой механизм используется для фильтрации;

Как имплементированы протоколы.

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

Имплементация модели OSI в операционной системе начинается со строго определенных уровней. В данном случае всё начинается на уровне "Канальном" и заканчивается на уровне "Транспортном". Имплементация на каждом уровне своя:

Канальный уровень - состоит из MAC и LLC, соответственно и частей имплементации должно быть две:

MAC - miniportdriver это драйвер, который контролирует сетевой интерфейс;

LLC - protocol driver - драйвер, который используется для обработки данных от сетевых устройств;

Уровень сети - protocol driver - драйвер, который используется для обработки данных от сетевых устройств;

Уровень транспорта - protocol (transport) driver;

Вот и выявилось коренное отличие Windows от Linux - вся логика работы сетевой подсистемы разбита на множество элементов. Каждое устройство, каждый протокол и абстракция имплементированы не в ядре, а в модуле ядра - драйвере, который может быть загружен ядром по запросу. Что это значит для нас? У нас нет исходного кода данных драйверов, а значит мы не можем использовать подход, который использовали при изучении ОС Linux.

Как же быть? При разработке эксплойтов исследователи в качестве отправной точки для восстановления структур внутри ядра Windows используют проект с открытым исходным кодом - ReactOS. Попробуем сделать тоже самое. Давайте найдем части подсистемы и затем спроецируем найденную информацию на реальную ОС Windows.

На экране ниже приведен снимок директории с основными драйверами для сетевой подсистемы:

Попробуем найти такие же файлы в реальной ОС. Заглянем в директорию "%Windows%". В качестве исследуемой системы возьмем Windows 7.

Часть файлов действительно имеет названия файлов, которые присутствуют в реальной ОС.

Один из способов проверки функционала уже скомпилированного приложения - прочитать используемые им строки. Можем для этого воспользоваться утилитой strings.exe для tcpip.sys :

Похоже, что данные по работе с сетевой подсистемой можно обнаружить именно в этом драйвере. Поищем функции, которые позволяют фильтровать трафик. Как их идентифицировать?

В операционной системе Windows за всё время её существования было 2 технических спецификаций на основании которых создавались драйвера для сетевого взаимодействия: TDI и WinSock. И все эти спецификации использовали отдельный драйвер для того чтобы можно было собирать весь функционал - NDIS. Значит большая часть функций сконцентрирована в этих драйверах:

Но в них все равно нет функций, которые бы могли фильтровать трафик. Почему так? Дело в том, что до Windows 7 фильтрация трафика как такового была имплементирована в отдельных драйверах, которые настраивались за счет интерфейса Windows. Начиная с Windows 7 была реализована так называемая Windows Filtering Platform, которая определила часть драйверов в специальную категорию, которая и призвана фильтровать трафик.

Часть этих фильтров можно найти по обычному поиску в директориях ОС:

Используем утилиту strings.exe на файлы FWPKCLNT.SYS и wfplwf.sys :

Выше представлена часть строк, которые обнаружились в файле FWPKCLNT.sys , файл wfplwf.sys содержал только названия функций. Почему тогда они здесь вместе? Дело в том, что в импортах wfplwf.sys есть функция, которая берется из файла FWPKCLNT.sy s:

Имплементация всех объектов и механизмов в ядре для работы с протоколами - файлы из директории %Windows%\System32\Drivers . Основные из них - netio.sys, ndis.sys, tdi.sys.

Фильтрацией занимаются драйвера WFP: FWPKCLNT.sys , wfplwf.sys .

Имплементируются через отдельные одноименные файлы, например: tcpip.sys

В ОС Linux мы не задумывались о том как приложения получают доступ к структурам ядра и работают с сетью. Там более-менее всё очевидно и только один шаг до функций, но для Windows всё работает по принципу Callback`ов. Поэтому скорее всего будет несколько оберток для взаимодействия. Попробуем найти эти файлы.

Для поиска файлов, которые используются в качестве обертки-библиотеки, можно использовать следующий метод. Для этого создадим мини приложение, которое будет работать с сокетами, принимать и отправлять данные. Исходный код приложения:

Запускаем файл в ОС, если не возникло никаких ошибок, то необходимо параллельно запустить инструмент Process Explorer. С помощью этого инструмента мы подсмотрим, чем занимается поток, пока ждет соединения. На картинке ниже отображены все описанные действия:

Слева изображен стек вызовов функций, которые задействованы в процедуре настройки сокета и перевода его в состояние bind. Этот набор файлов - mswinsock.dll (Win Sock 2 Service) и WS2_32.dll (Windows Socket 2). Данные библиотеки используются для того, чтобы предоставить приложениям функции по работе с сокетами в ОС Windows.

Стоит отметить, что последовательность функций, которые вызываются для работы сокета в ОС, не виден в Process Explorer`е. Если нужно восстановить и эти данные, то нужно использовать отладчик ядра.

Таким образом, проводить исследование подсистем любых ОС и их механизмов можно с исходным кодом и без — достаточно выбрать необходимый набор инструментов, а также доступные методы, источники знаний.

Сетевая подсистема Linux

Начнем наше исследование с вот такой интересной картинки:

Картинка представляет собой структуру директорий исходного кода ядра ОС Linux. На ней видно, что сетевая подсистема вовсе не самая большая часть операционной системы. По правде говоря, можно собрать ядро и без этой части. Сегодня это вариант только для embeded систем, в общем случае без сети представить Linux сложно.

Код, который относится к сетевой подсистеме, находится в директории "net". Посмотрим, из чего он состоит.

На картинке выделены названия файлов, которые описывают основные структуры для работы с сетью. Это создание сокетов, хранение пересылаемых данных и работа с фильтрующей подсистемой bfp . Именно этот код переиспользуется для остальной части сетевой подсистемы.

Оставшиеся файлы в директории "net" описывают работу ядра с различными протоколами. Интересным моментом здесь является то, что фильтрующая подсистема имеет какие-то файлы только в некоторых протоколах и подсистемах:

Прямоугольниками выделены те протоколы и подсистемы, которые содержат файлы netfilter . Как видно из картинки, механизм фильтрации трафика работает не со всеми протоколами. Также интересно то, что он присутствует не только в протоколах, но и в более высокоуровневой абстракции - bridge. Теперь понятно, почему bridge от Linux можно настроить настолько гибко и контролировать пересылаемые данные.

Что в итоге? Всего по 4м картинкам структуры исходных кодов ядра мы уже обладаем информацией о том, какие поддерживаются протоколы в ядре Linux, какие механизмы интегрированы в протоколы для контроля и фильтрации и где найти базовые элементы, которые позволяют использовать сеть. Попробуем найти эту информацию и в ОС Windows.

Сетевая подсистема в ОС

Для будущих студентов курса «Сетевой инженер» и всех интересующихся подготовили полезную статью.

Также приглашаем на открытый вебинар по теме «NAT — не Firewall». Участники вебинара вместе с экспертом рассмотрят NAT и его использование, почему NAT != firewall, а также различные виды конфигураций для разных ситуаций.

В данной статье будет проведено исследование сетевой подсистемы ОС Windows и Linux, а также предложен план изучения подсистем операционной системы. Основная задача исследования - понять, из чего состоит сетевая подсистема; какие поддерживает протоколы из коробки; какие дополнительные механизмы использует в своей работе.

Disclamer: Статья описывает данные, которые с точки зрения автора помогут понять, как работают операционные системы с моделью TCP/IP, и не претендует на полноту.

Инструментарий и метод исследования

Для исследования операционной системы будем использовать следующие инструменты:

Операционная система Linux:

Visual Studio Code;

Операционная система Windows:

Инструменты подобраны таким образом, чтобы можно было охватить максимальное количество форматов файлов, которые можно обнаружить в ОС. Для исходного же кода главный инструмент - редактор, который позволяет удобно переходить от исходника к исходнику для разбора кода.

В нашем исследовании будем руководствоваться двумя правилами:

Используем всю информацию из документации операционных систем;

Проверяем правдивость описанных данных. Для структур данных:

В ОС Windows исследуем соответствующие функционалу dll, sys файлы;

В ОС Linux исследуем исходные коды и отдельные ветки ядра;

Теперь определимся с проблемами, которые вероятно будут нас преследовать на протяжении всего исследования.

Проблемы при исследовании ОС Linux

Основной функционал подсистемы целиком находится в ядре. К счастью, исходный код доступен в сети. Исследование исходного кода таких больших проектов всегда довольно сложная задача. На её сложность может влиять несколько факторов:

у каждого исследователя разный уровень экспертизы в области языка программирования, который используется в исходном коде;

у каждого исследователя есть свой собственных подход на интерпретацию полученной информации.

ограниченности исследования по времени;

объем исходного кода;

принятые правила кодирования проекта.

Как минимизировать количество действий исследователя, чтобы получить как можно больше полезной и интересной информации? Огромную роль играет правильно настроенное рабочее место. В нашем случае верную настройку определяет набор инструментов, который мы описали в разделе "Инструментарий и метод исследования". Также можно применить небольшой лайфхак и не рассматривать каждую строку исходников ядра, а рассматривать только высокоуровневые элементы. Это сэкономит время на изучение языка программирования и даст возможность разобраться, что к чему. Попробуем применить эту тактику на практике.

Описание ситуации с ошибкой AFD ID 16001

Как я и писал выше, у меня есть гипервизор VMware ESXI 6.5, на котором есть виртуальная машина с установленной Windows Server 2012 R2. На данной виртуальной машине развернута роль RDSH, являющийся членом RDS фермы. Ранее данная виртуальная машина приходила в такое состояние, что пользователи не могли выйти из системы, через кнопку пуск, их сессии просто зависали, в результате чего они не могли подключиться заново. Я вам там приводил ряд мер, которые давали некоторые улучшения в данном вопросе, но сегодня данная виртуальная машина опять попала в такое состояние. После принудительной перезагрузки, я обнаружил уже новое предупреждение, которое косвенно может влиять на работу сервиса, а именно было предупреждение:

Источник AFD, Код события ID 16001: Обнаружен фильтр TDI (\Driver\vnetflt). Он не сертифицирован корпорацией Майкрософт и может привести к нестабильной работе системы

Что такое драйвер vnetflt

Мне стало интересно, что это за драйвер, который может приводить мою операционную систему к нерабочему состоянию. Я прекрасно помнил, что Windows все свои драйвера хранит в одной папке C:\Windows\System32\Drivers. Если зайти в свойства vnetflt.sys и открыть вкладку "Подробно", то можно обнаружить, что его разработчик Vmware и описание у драйвера vnetflt.sys показывает "VMware Guest Introspection Network Fit".

Оказывается драйвер vnetflt.sys входит в состав драйверов интеграции VMware Tools и поддерживает функцию мониторинга активности NSX для vSphere. Однако он не используется никакими функциональными возможностями конечной точки vShield.

VMware NSX - это семейство программных продуктов для виртуальных сетей и безопасности, созданное на основе интеллектуальной собственности VMware vCloud Networking and Security (vCNS) и платформы сетевой виртуализации (NVP) Nicira.

Программно-определяемые сети ( SDN ) NSX являются частью концепции программно-определяемых центров обработки данных (SDDC) VMware, которая предлагает облачные вычисления на основе технологий виртуализации VMware. Заявленная цель VMware с NSX - предоставить виртуальные сетевые среды без интерфейса командной строки (CLI) или другого прямого вмешательства администратора. Виртуализация сети абстрагирует сетевые операции от базового оборудования на уровень распределенной виртуализации, так же как виртуализация серверов делает для вычислительной мощности и операционных систем (ОС). VMware vCNS виртуализирует уровень 4-7 ( L4-L7 ) сети. NVP от Nicira виртуализирует сетевую структуру, уровень 2 (L2) и уровень 3 (L3).

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

Важные особенности NSX

Коммутация: логические коммутаторы NSX используют уникальные сетевые идентификаторы Virtual Extensible LAN (VXLAN) для создания логического расширения наложения для сети L2, к которому затем могут быть логически подключены приложения и виртуальные машины-арендаторы (VM). Эти логические широковещательные домены обеспечивают большую гибкость и ускоряют развертывание, обеспечивая при этом характеристики виртуальной ЛВС (VLAN) без риска разрастания.
Маршрутизация: NSX выполняет маршрутизацию как с логическими распределенными маршрутизаторами, которые создают маршруты между виртуальными сетями в ядре гипервизора и физическими маршрутизаторами для масштабной маршрутизации с режимом активный-активным и переключением при сбое.
Распределенный межсетевой экран: распределенный межсетевой экран NSX представляет собой встроенный в ядро гипервизор межсетевой экран, который распространяется по узлу ESXi. Сетевой администратор может создавать настраиваемые политики брандмауэра, которые применяются на уровне виртуальной сетевой карты (vNIC), для обеспечения служб брандмауэра с отслеживанием состояния для виртуальных машин и улучшения видимости и контроля для виртуализированных сетей и рабочих нагрузок.
Балансировка нагрузки : NSX предлагает балансировщик нагрузки L4-L7, который перехватывает, транслирует и манипулирует сетевым трафиком для повышения доступности и масштабируемости корпоративных приложений. Балансировщик нагрузки NSX включает поддержку разгрузки Secure Sockets Layer (SSL) для сквозной проверки и проверки работоспособности сервера. Балансировщик нагрузки L4 предлагает балансировку нагрузки на основе пакетов, которая отправляет пакет на определенный сервер после его манипулирования; Балансировщик нагрузки L7 предлагает балансировку нагрузки на основе сокетов, которая устанавливает клиентские и серверные соединения для одного запроса.
Виртуальная частная сеть (VPN): NSX включает в себя возможности VPN для межсетевого взаимодействия и удаленного доступа, а также неуправляемую VPN для служб облачных шлюзов.
Шлюз NSX Edge: Шлюз NSX Edge представляет собой виртуальную машину, которая ведет себя как устройство для выполнения маршрутизации L3, межсетевого экрана, виртуальных частных сетей «сайт-сайт», балансировки нагрузки и многого другого. Эта функция также предлагает поддержку мостов VXLAN к VLAN для беспрепятственного подключения к физическим нагрузкам.
Интерфейс прикладного программирования (API): NSX использует API на основе представления о состоянии (REST API), чтобы упростить интеграцию сторонних продуктов и услуг и интегрировать NSX с облачным управлением для дополнительных возможностей автоматизации.
Операции: Собственные возможности операций включают в себя центральный интерфейс командной строки, анализатор портов коммутатора (SPAN), экспорт информации о потоках IP (IPFIX), диспетчер правил приложений (ARM), мониторинг конечных точек и интеграцию с VMware vRealize Suite для упреждающего мониторинга, аналитики и устранения неполадок.
Динамическая политика безопасности: NSX Service Composer позволяет сетевому администратору предоставлять и назначать приложениям сетевые службы и службы безопасности. Администратор также может использовать Service Composer для создания динамических групп безопасности с настраиваемыми фильтрами, такими как объекты и теги VMware vCenter, тип ОС и роли Active Directory (AD).
Управление облаком: NSX изначально интегрируется с vRealize Automation и OpenStack для управления облаком.
Кросс-vCenter Networking and Security (Cross-VC NSX): эта возможность масштабирует NSX vSphere через границы vCenter и центров обработки данных. Это позволяет сетевому администратору обращаться к пулу емкости между vCenters, упрощать миграцию центра обработки данных, выполнять vMotions на большие расстояния и выполнять аварийное восстановление (DR).
Управление журналом : NSX интегрируется с vRealize Log Insight, который получает записи журналов от хостов ESXi, использует пакеты контента для обработки информации, содержащейся в каждой записи журнала, и выявляет проблемы в развертывании NSX.

NSX варианты использования

Согласно VMware, три основных варианта использования, стимулирующих внедрение NSX, - это микросегментация, автоматизация IT и DR. Эти варианты использования направлены на решение проблем, обычно связанных с виртуализацией сети, таких как низкая производительность трафика и недостаточная безопасность.

Первый из этих вариантов использования, микросегментация, касается безопасности сети. Микросегментация использует общую сетевую практику сегментации и применяет ее на детальном уровне. Это позволяет сетевому администратору установить периметр безопасности с нулевым доверием вокруг определенного набора ресурсов - обычно рабочих нагрузок или сегментов сети - и добавить функциональность брандмауэра east-west в центр обработки данных. NSX также позволяет администратору создавать дополнительные политики безопасности для определенных рабочих нагрузок, независимо от того, где они находятся в топологии сети.

NSX использует автоматизацию центра обработки данных для быстрой и гибкой настройки сети. Сетевой администратор может быстро обеспечить новую сеть или сетевой сегмент рабочими нагрузками, ресурсами и политиками безопасности, уже привязанными к нему. Это устраняет узкие места и делает NSX идеальным для тестирования приложений и работы с неустойчивыми рабочими нагрузками, которые NSX может логически изолировать в одной и той же физической сети.

Автоматизация также важна для DR. NSX интегрируется с инструментами оркестровки, такими как vSphere Site Recovery Manager (SRM) , который автоматизирует аварийное переключение и DR. В сочетании с NSX SRM можно использовать для репликации хранилища, а также для управления и тестирования планов восстановления. SRM также интегрируется с Cross-VC NSX. Представленный в NSX 6.2, Cross-VC NSX обеспечивает логическую сеть и безопасность для нескольких vCenters, что упрощает применение согласованных политик безопасности без необходимости ручного вмешательства. При использовании в сочетании с Cross-VC NSX SRM автоматически сопоставляет универсальные сети через защищенные сайты и сайты восстановления.

Как отключить или удалить vnetflt.sys

Чтобы отключить TDI vShield Endpoint в Windows, вам необходимо открыть редактор реестра Windows и перейти по пути:

Находим тут ключ Start и меняем его значение с 2 на 4. После чего сохраняем настройки и перезагружаем компьютер или сервер. После этого в логах Windows у вас не будет предупреждения ID 16001.

Я же больше придерживаюсь мнения, что если вы что-то не используете, значит это лучше отключить, а если можно, то удалить. Я предлагаю вам удалить компонент TDI vShield Endpoint. Для этого вы можете либо в момент обновления VMware Tools его не выбирать или же можете изменить установленные драйвера, для этого откройте панель управления, раздел "Программы и компоненты"

Этот драйвер можно удалить только в том случае, если на виртуальной машине установлена версия VMware не менее 10.x (Где скачать последнюю версию VMTools читайте по ссылке)

Выбираем VMware Tools и нажимаем кнопку "Изменить".

В разделе "VMCI Drever" снимите галки "NSX File Introspection Driver" и "NSX Network Introspection Driver", после чего нажимаем "Next". В результате чего у вас будет переустановлен Vmware Tools, но уже без данных компонентов. Перезагружаем вашу систему и проверяем отсутствие предупреждений ID 16001.

Так же хочу отметить, чтобы вы проверили в настройках своей виртуальной машины, что у вас в качестве сетевого адаптера используется тип VMXNET3. (Про типы сетевых адаптеров VMware ESXI читайте по ссылке)

Tdi driver что это

Читайте также: