Ошибка e0000217 при установке драйвера

Обновлено: 04.07.2024

Проблема с драйвером MTP. Такое иногда случается, но не на всех компьютерах. Данная проблема устраняется очень просто и быстро, ниже я подробнее ее опишу;
Неправильные настройки в самом устройстве. Как показывает практика, такая причина возникает в 1% случаев, но тем не менее возможно у вас именно она является причиной возникновения ошибки;
Устаревшие драйвера. Эта проблема тоже имеет место быть, но, также как и предыдущие – данная причина возникновения ошибки устраняется простым обновлением драйвера для вашей операционной системы.

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

Способ 1

Первым делом я рекомендую вам испробовать именно этот способ решения проблемы. Проделать все нижеприведенные действия можно буквально за несколько минут. Следуйте шагам:

Если ваш телефон подключён по USB к компьютеру, то отключите его;
Теперь вам нужно выполнить запуск редактора реестра, для этого достаточно нажать сочетание клавиш Windows (кнопка в левом нижнем углу с изображением логотипа Microsoft) + R;
В появившемся окне вам нужно ввести слово “regedit” и нажать кнопку OK;

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

Теперь снова подключите ваше мобильное устройство к персональному компьютеру и проверьте исчезла ли, возникающая ранее, ошибка.

Способ 2

Если предыдущий способ не помог, то давайте попробуем покопаться в настройках самого мобильного устройства. Выполните следующие действия:

Возьмите ваш Андроид гаджет и перейдите в его настройки;
Далее выберите раздел под названием приложения;
В этом разделе выберите пункт разработка;
Убедитесь что стоит галочка напротив пункта “Отладка по USB”, если галочка не стоит, то поставьте ее.

Важно: если пункта разработка не видно, то сделайте следующее: перейдите в раздел “Об устройстве” и около 10 раз нажмите на номер сборки. Тем самым вы активируете пункт “Разработка”.

Способ 3

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

Теперь попробуйте снова подключить ваш мобильный Андроид гаджет к персональному компьютеру и проверьте исчезла ли ошибка USB.

На этом у меня все. Если возникли какие-либо вопросы, замечания или дополнения к опубликованному выше материалу, то можете поделиться ими в комментариях к этой записи. Я же, в свою очередь, постараюсь ответить вам как можно быстрее и как можно подробнее.

Если статья была для вам полезна, то вы можете отблагодарить автора статьи опубликовав ссылку на данный материал в своих аккаунтах социальных сетей, для этого нажмите одну из кнопок расшаривания расположенных ниже. Не забывайте добавить данный ресурс в закладки, думаю он вам еще не раз пригодится в процессе эксплуатации вашего Андроид устройства. До встречи в следующих, несомненно, полезных материалах.

Обсуждаемая сегодня ошибка возникает при подключении телефона к компьютеру. Происходит такое по разным причинам. Это может быть отсутствие необходимых компонентов в системе или, наоборот, присутствие лишних. Все эти факторы мешают корректной установке медиадрайвера для мобильных устройств, который позволяет «винде» общаться со смартфоном. Далее мы рассмотрим все возможные варианты устранения данного сбоя.

Способ 1: Редактирование системного реестра

Реестр представляет собой набор системных параметров (ключей), определяющих поведение системы. Некоторые ключи в силу различных причин могут мешать нормальной работе. В нашем случае это единственная позиция, от которой нужно избавиться.

«Выполнить»

Win+R

Жмем «Найти далее». Обратите внимание, что должна быть выделена папка «Компьютер».

Если ключи не найдены или способ не сработал, значит, в системе отсутствует нужный компонент, о котором и поговорим в следующем параграфе.

Способ 2: Установка MTPPK

MTPPK (Media Transfer Protocol Porting Kit) – драйвер, разработанный Майкрософт и предназначенный для взаимодействия ПК с памятью мобильных устройств. Если у вас установлена «десятка», то данный способ может не принести результата, так как эта ОС способна самостоятельно загружать подобное ПО из интернета и оно, скорее всего, уже установлено.

Установка производится предельно просто: запускаем загруженный файл двойным кликом и следуем подсказкам «Мастера».

Частные случаи

Далее мы приведем несколько частных случаев, когда решения проблемы являются неочевидными, но тем не менее эффективными.

Попробуйте выбрать тип подключения смартфона «Камера (PTP)», а после того как устройство будет найдено системой, переключить обратно на «Мультимедиа».
В режиме разработчика отключите отладку по USB.

Подробнее: Как создать точку восстановления в Windows 10, Windows 8, Windows 7, Windows XP

Заключение

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

Мы рады, что смогли помочь Вам в решении проблемы.

Отблагодарите автора, поделитесь статьей в социальных сетях.

Опишите, что у вас не получилось. Наши специалисты постараются ответить максимально быстро.

Одна из причин, почему не устанавливается драйве, это отсутствие цифровой подписи.

Windows 8.1 блокируют установку драйверов без цифровой подписи (или измененных после ее нанесения). Делается это в целях безопасности, так как установка не подписанных драйверов или подделанных (возможно, с помощью вируса), может привести к непредсказуемым последствиям, вплоть до переустановки системы.

Устанавливать драйвера без цифровой подписи или нет?

В этом случае все зависит от того, для чего необходимо установить не подписанные драйвера. Если необходимо установить драйвера для старого устройства, например сканера, то временно можно разрешить системе установить не подписанные драйвера. Возможно вам нужен драйвер на телефон с процессорами МТК, которые часто идут без подписи, это китайские, тайваньские и т.д. производители. Поэтому вам в обрез нужно обойти систему Windows, чтобы достичь своей цели.

И вот мы переходим к самой процедуре отключения проверки цифровой подписи драйверов:

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

1. Перемещаем курсор в нижний правый угол экрана выбираем пункт Параметры или нажимаем клавиши Win + I . Нажимаем клавишу shift ,и держа нажатой, выбираем Выключение и Перезагрузка.

После перезагрузки в появившемся окне нажимаем Диагностика.

В появившемся окне Диагностика выбираем Дополнительные Параметры.

Следующим нашим шагом будет, переход в Параметры Загрузки.

В меню Параметры Загрузки , мы жмём Перезагрузить.

Этот шаг будет завершающим. В Параметрах Загрузки нам нужно нажать клавишу F7 или 7 и дело сделано. Компьютер или Ноутбук перезагрузиться и система будет открыта для установки нужного нам не подписанного драйвера.

Есть к вам небольшая просьба: Оставьте пожалуйста комментарий на эту статью и поделитесь ей со своими друзьями в Соц Сетях.

Вероятно многие встречались с таким вот «партизаном» при старте или завершении приложения:

Если честно, раньше я как-то даже не задумывался по поводу данного исключения, т.к. в моих проектах оно явление редкое, пока однажды у целой череды пользователей не начала воспроизводится именно 217-я ошибка.
Впрочем, даже тогда я не пошел по правильному пути и просто добавил дополнительный уровень логирования в проект, по результатам которого достаточно оперативно нашел причину и исправил ее.
Но, по сути, я просто потратил свое время…

И тратил бы его в дальнейшем, если бы на днях со мной не связался Виктор Федоренков и не рассказал о своих мыслях по поводу ошибки за номером 217.

Теория и анализ проблемы

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

Для начала я немного освежил мои представления об ошибках в принципе, перечитав часть статьи «Обработка ошибок — глава 1.2.2» за авторством Александра Алексеева, откуда вынес информацию о том, что ошибка 217 будет отображена в том случае, если не инициализирован модуль SysUtils, причем это у Александра проиллюстрированно достаточно наглядно:

Открыть картинку в полный размер…

На основании данной картинки можно сделать грубый вывод: пока SysUtils жив — все исключения должны отображаться в нормальном виде, о чем идет отдельное упоминание:

Ну что-ж давайте проверим, пишем код, в котором SysUtils должна быть финализирована позже модуля Unit1, в котором искусственно генерируем исключение:

Билдим, запускаем, закрываем форму и… Runtime error 217.

Утверждение о том, что 217 отображается после финализации SysUtils полностью верное, но давайте-ка посмотрим на сам код финализации:

Смотрите что происходит: в процедуре FinalizeUnits вызываются все финализирующие процедуры, адреса которых расположены в массиве InitContext.InitTable^.UnitInfo в том порядке, в котором происходила их инициализация, т.е. самые первые расположены в начале массива (а финализация идет с конца).
Где-то в самом низу расположен и SysUtils + System, ну а мы, с нашим модулем Unit1 где-то в самом верху.
Но вдруг происходит исключение в нашем модуле и «бабах», порядок катарсиса нарушен.

После «бабах» FinalizeUnits вызывается повторно, пропуская наш модуль, вызвавший исключение, вследствие чего разрушается SysUtils и разные, встречающиеся по пути, class destructor-ы, до кучи грохается System с менеджером памяти (сидящий одним из первых в начале списка), после чего идет контрольный выстрел в лоб — RAISE, вот тут-то мы и приплыли — здравствуй 217.

А что если произойдет исключение в секции инициализации любого модуля?

Да все тоже самое:

Делаем вывод: любое необработанное исключение в секциях инициализации или финализации будет приводить к потере описания исключения и приводить к ошибке 217.

Отключаем финализацию модулей

В самом начале обсуждения Виктором был предложен достаточно эффективный способ обхода данной ошибки.

Его анализ заключался в следующем: общая инициализация обработчика исключений производится в процедуре InitExceptions модуля SysUtils, а финализация вызовом DoneExceptions.

Как вариант решения был предложен следующий код, который нужно подключить к файлу проекта самым первым модулем (будет работать начиная с D2005 и выше):

Если честно — аплодировал стоя.
Вот он: хак в самом грязном виде как он есть — такие вещи могут делать только те, кто действительно понимает, чем это грозит :)
И данный модуль вывел работу нашего IT отдела примерно на три часа — это была жесткая дискуссия :)

Но, впрочем, давайте разберем логику работы данного кода:
Суть его проста, необходимо выйти на данные о загруженных модулях (включая BPL) в том виде, в котором их понимает Delphi приложение. Это было сделано посредством доступа к началу однонаправленного списка структур TLibModule. Первым элементом списка будет структура, описывающая текущий образ, откуда нам нужно всего-то и получить данные о структуре UnitInfo, которая содержит в себе данные как о количестве инициализированных модулей, так и об адресах их процедур инициализации и финализации в виде записи PackageUnitEntry.

Блокирование финализации модулей происходит посредством присвоения параметру FInit значения nil у каждой записи PackageUnitEntry.

При обниливании данного параметра FinalizeUnits не сможет произвести вызов обработчика и в итоге тот самый raise, о котором я писал выше, сможет достаточно корректно произвести отображение возникшего исключения.

Но вот дальше все сложнее.

Пытаемся причесать хорошую мысль

Идея здравая и причины понятны, но вот как-же так, ресурсы все-же не освобождены, FastMem перестанет нормально работать (она собирает утечки как раз при финализации), да и совместимости маловато, к примеру, как я и сказал выше, под Delphi 7 данный код вообще работать не сможет.

После первого часа обсуждений в IT отделе мы даже умудрились прийти и к такому выводу: «да и хрен с ними с SysUtils и System — что-то критичного они за собой не несут».
А потом, опять начали спорить — ну не устраивал нас этот подход, вроде все хорошо, но не аккуратненько как-то.

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

А выводится оно посредством передачи управления на ExceptHandler, в коде которого нет ничего секретного.
А что мы делаем убирая финализацию модулей?
Правильно, заставляем вызваться его-же.

Попробуем-ка проэмулировать вызов ExceptHandler.
Пишем тестовый юнит и подключаем его к проекту самым первым:

Запускаем на выполнение и…

Получилось.

Встроившись в цикл финализации, мы отобразили произошедшее исключение и продолжили финализацию дальше вызовом Halt(1).

В итоге задача решена, грамотно и документировано, и совместимо с Delphi 7, но…

А не развить ли идею?

Есть такое понятие, как «наведенные ошибки», т.е. ошибки произошедшие из-за того что перед ними тоже произошла ошибка.

Ну к примеру, функция А, которая должна возвращать экземпляр некоего класса и функция Б, использующая этот экземпляр в работе. К примеру в функции А произошло необработанное исключение (например нет доступа к файлу) и она не создала класс, а потом где-то гораздо позже по коду приложения процедура Б выполняет обращение к этому экземпляру и в итоге происходит Access Violation.

Тоже самое может произойти и в процедурах инициализации/финализации, причем исключение, произошедшее в финализации скроет от нас саму причину.

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

Мало у кого в системе присутствует диск «А» поэтому результатом этого кода будет либо «Runtime error 216» (именно 216, а не 217), либо, если подключим код из предыдущей главы:

Exception EAccessViolation in module Project2.exe at 001B1593.
Access violation at address 005B1593 in module 'Project2.exe'. Read of address 00000000.

А ведь причина то кроется в самом первом исключении, которое нами не отображается и с наскока разобраться в причине ошибки не получится.

Здесь идея проста, функция GetNextException по сути повторяет вызов AcquireExceptionObject, но после своего вызова не теряет ссылку на следующее в очереди исключение, а запоминает адрес следующего фрейма во внешней переменной.
После чего все исключения заносятся в список (самое последнее будет первым в списке) и выводятся программисту с соблюдением очередности, в результате чего нам будет сразу понятно, что сначала произошло вот это:

И уже только после него пошли всякие там AV.

Теперь по поводу остальных кодов ошибок.
Почему я начал именно с «Runtime error 217»?
Ну потому что она наиболее легко воспроизводима, а так технически, используя выше приведенный модуль, мы получим на руки вполне нормальное описание всех возможных Runtime ошибок, коих в наличии у нас вон сколько:

Вот таким небрежным кодом, мы можем получить то, о чем нам не хочет говорить ошибка под кодом 217.

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

А если нет — значит буду вторым.

Отдельный респект соавтору и вдохновителю данной статьи — Виктору Федоренкову.

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