Ошибка с именем события BEX64 обычно возникает после сбоя Проводника Windows или в результате неполадок приложения или игры. По сообщениям пользователей, она происходит случайным образом, а также при выполнении программ, которые интенсивно используют ресурсы системы.
Чем вызвана ошибка?
Есть несколько причин, которые в конечном итоге вызывают проблему с именем события Bex64:
- Конфликт со службой amBX. Если столкнулись с ошибкой при запуске GTA 5 и перед этим установили модуль типа amBX, то, скорее всего, имеете дело с конфликтом между двумя процессами. Для решения проблемы нужно отключить службу этого модуля.
- Конфликт с другими программами. Проблема может возникнуть при использовании сторонних программ: DEDgear, AmBX, Razer Synapse, Teamviewer и прочих. Для определения проблемного приложения нужно выполнить чистую загрузку системы.
- Блокировка, наложенная фильтром DEP (Data Execution Prevention). Если доверяете приложению, то сможете устранить проблему путем отключения фильтра из командной строки с правами администратора.
Отключение службы amBX
Если видите ошибку BEX64 при каждом запуске GTA 5, возможно, имеете дело с конфликтом между игрой и amBX или аналогичной службой. Чтобы устранить эту ошибку, попробуйте отключить службу.
Почему игры не запускаются на Windows 7
Откройте экран системных служб командой services.msc , запущенной из окна Win + R. Если отобразится запрос контроля учетных записей, подтвердите его, чтобы предоставить доступ администратора.
В списке найдите amBX, щелкните по ней правой кнопкой мыши и выберите Свойства.
На вкладке Общие щелкните на выпадающее меню типа запуска и выберите значение «Отключена». Примените изменения, закройте окно и перезагрузите компьютер. Проверьте, прерывается ли запуск GTA 5 ошибкой BEX64.
Устранение конфликта сторонних программ
Если сталкиваетесь с ошибкой при использовании Проводника Windows или запуске приложения, то, скорее всего, в системе работает фоновый процесс, которые этому препятствует. По сообщениям пользователей, это может быть антивирус или брандмауэр, а также сторонние темы и программы оптимизации производительности. Чаще всего сбой с именем события BEX64 вызывают программы: MacType, DEDgear, AmBX, Razer Synapse и Teamviewer.
В этом случае решение состоит в удалении подозрительное программного обеспечения, которое конфликтует с другими приложениями. Для его определения нужно выполнить чистую загрузку, затем повторить то действие, которое вызывало ошибку BEX64. Если сбои в этом режиме прекратятся, то проблема действительно возникает из-за стороннего процесса.
В режиме чистой загрузки разрешены только собственные процессы Windows. Для его выполнения откройте окно Конфигурации системы командой msconfig из окна Win +R.
На вкладке Службы отметьте флажком поле «Не отображать службы Майкрософт» и щелкните на кнопку «Отключить все». Затем на вкладке Автозагрузка перейдите в Диспетчера задач и отключите запуск приложений, которые стартуют вместе с системой. После перезапуска будет выполнена чистая загрузка.
Что делать если не запускается приложение на ПК а так же в steam? Есть решение !
Если при выполнении того действия, которое вызывало ошибку BEX64, сбои прекратятся, то причина в какой-то сторонней программе. Чтобы ее определить, включайте по несколько служб и программ, перезагружая регулярно компьютер. При обнаружении проблемного ПО, его нужно удалить.
Откройте окно «Программы и компоненты» командой appwiz.cpl из окна Win + R.
Прокрутите список установленных приложений и найдите программное обеспечение, которое нужно удалить.
Щелкните по нему правой кнопкой мыши и выберите «Удалить». Следуйте инструкциям на экране, чтобы завершить процесс, затем перезагрузите компьютер.
Отключение фильтра DEP
Фильтр Data Execution Prevention – это набор программных функций, которые выполняют дополнительные проверки памяти, чтобы предотвратить запуск вредоносного кода в системе. Однако при определенных обстоятельствах этот фильтр безопасности может препятствовать правильному функционированию отдельных приложений. Проблема часто возникает, когда пользователи пытаются запустить определенные игры, построенные таким образом, что в конечном итоге конфликтуют со средой DEP. Для отключения фильтра, выполните следующие шаги.
Откройте командную строку с помощью поиска Windows и запустите ее с доступом администратора.
В консоли наберите указанную команду и подтвердите ее запуск на Enter:
bcdedit.exe /set nx AlwaysOff
После успешной обработки команды фильтр будет отключен.
Перезагрузите компьютер и попробуйте запустить игру, которую не удавалось из-за ошибки BEX64.
Источник: compuals.ru
Принудительно запустить приложение в 32-битном процессе в 64-битной Windows
Есть ли способ заставить приложение работать в 32-битном режиме на 64-битной Windows?
Мой ОС Windows 7 64 бит.
задан Shahin 160
1 ответ 1
Если вы пытаетесь запустить 64-битную программу, нет способа запустить ее как 32-битную. Формат исполняемых файлов различен, системные вызовы рассчитаны на 64-разрядность. Просто это несовместимо с 32-битной средой. Вот почему вы не можете запустить 64-разрядный исполняемый файл в 32-разрядных операционных системах и 32-разрядных процессорах.
Если вы пытаетесь запустить 32-разрядную программу, программа уже запускается как 32-разрядная. 64-разрядные процессоры совместимы с 32-разрядными программами. 64-битная Windows (или любая другая 64-битная операционная система) заменяет 32-битные системные вызовы на 64-битные с помощью эмуляции или любого другого метода.
Итак, x-bit — это процессор, операционная система и исполняемый файл; это не режим. Вы не можете заставить 64-битный исполняемый файл работать как 32-битный. 32-разрядные указания в списке процессов Windows показывают только то, что программа на самом деле является 32-разрядной и, следовательно, выполняется в режиме эмуляции 32-разрядных системных вызовов. Вы не можете заставить это искусственно.
Источник: poweruser.guru
Programming stuff
Я уже второй раз за последнее время сталкиваюсь с разными проблемами запуска «управляемых» приложений под 64-битным операционками, так что думаю, пришло время немного об этом рассказать.
Итак, программирование на платформе .Net делает еще один шаг по отделению прикладного программиста от всяких низкоуровневых платформенно-зависимых вещей типа размеров указателя, выравнивания, размеров целочисленных типов данных и других проблем, характерных для программирования на неуправляемых С/С++. Теперь все становится значительно проще и компиляторы таких языков программирования как C# или VB.Net не генерируют ассемблерные инструкции напрямую (хотя такая возможность и присутствует), вместо этого, результатом компиляции является код на промежуточном языке программирования, который затем компилируется во время выполнения JIT-компилятором в набор инструкций для конкретной платформы.
Если говорить за .Net 1.0 и 1.1, то в те старые добрые времена существовала только лишь 32-х разрядная версия CLR, что приводило к запуску .Net приложений на 64-х битных операционных системах в режиме совместимости (WOW64). Начиная с .Net 2.0 у разработчика появилась возможность выбора «целевой платформы» (Target platform), для которой это приложение предназначено. Обычно, этот выбор сводится к одному из следующих вариантов:
- Any CPU – конкретная платформа будет выбрана автоматически при запуске приложения;
- x86 – это старый добрый 32-х битный режим для процессоров семейства x86;
- x64 – это новый модный режим для 64-х битных процессоров;
- Itanium – а это старый и немодный режим для процессоров Itanium.
Все эти новшества полезны и замечательны, пока речь не заходит о взаимодействии с неуправляемым кодом, написанным на «чистом» С/С++. В таком случае, ваше приложение может сколько угодно говорить, что оно предназначено для “Any CPU”, но если одна из сборок использует неуправляемую dll, заточенную под определенную платформу, то чтобы заставить работать его под другой платформой придется попотеть.
64-х битная ОС и 32-х битная неуправляемая dll
Давайте рассмотрим следующую ситуацию: у нас есть «управляемое приложение», скомпилированное под “Any CPU”, при этом одна из сборок этого приложения использует неуправляемую 32-х битную dll (рисунок 1). За примером далеко ходить не нужно, поскольку многие существующие библиотеки все еще опираются на «нативные» реализации; так, например, многие драйвера доступа к базам данных, а также компоненты для работы с картами, реализованы именно таким образом.
Рисунок 1 – Запуск приложения с 32-х битной неуправляемой dll
Итак, при запуске приложения, операционная система проверяет информацию в заголовке исполняемого файла, чтобы определить в каком режиме его запускать: в режиме совместимости с 32-х битными приложения (т.е. в WOW64 режиме), или запускать его, как полноценное 64-х битное приложение. Если «управляемое» приложение собрано под “Any CPU”, то логично предположить, что будет выбран «честный» 64-х битный режим, который не требует никаких дополнительных «прослоек» (какой является режим WOW64), что позволит полностью воспользоваться всеми возможностями 64-х битной операционной системы. В результате будет запущена 64-х битная версия CLR, которая будет компилировать IL-код в соответствующий набор инструкций процессора. Но вот беда, процесс может быть запущен только в одном режиме и переключаться между ними он не в состоянии, поэтому, как только ваше приложение попытается загрузить неуправляемую библиотеку, оно рухнет со страшными криками в виде BadImageFormatException.
Решается эта проблема весьма просто, достаточно это приложение скомпилировать под платформу x86, явно указав это в настройках проекта (установив Platform target в x86). Это явным образом скажет операционной системе, что это приложение нужно запускать в режиме совместимости и никаких ошибок во время выполнения вы больше не получите. Именно поэтому в Visual Studio 2010 изменены настройки по умолчанию у всех «управляемых» исполняемых файлов. Теперь, у всех приложений вместо Any CPU Target platform установлен как x86. Это не касается сборок (Assembly), у них в настройках по-прежнему используется Any CPU, но это и не важно, поскольку операционная система все равно отталкивается от информации в заголовке исполняемого файла.
64-х битная ОС и 64-х битная неуправляемая dll
С первого взгляда может показаться, что на 64-х разрядной операционной системе не может быть проблем с 64-х битными неуправляемыми dll, однако две бессонные ночи (*) показали, что это совсем не так.
Итак, давайте рассмотрим следующий сценарий: у нас есть сборка, скомпилированная под Any CPU, которая использует неуправляемую 64-х битную dll, и все это дело используется из powershell-а (рисунок 2).
Рисунок 2 – Архитектура приложения
С первого взгляда, в такой архитектуре нет ничего криминального, и действительно, так оно и было, пока мы не попытались запустить все это дело через нестандартный планировщик (**), который оказался 32-х разрядным приложением. Все дело в том, что при попытке запустить управляемое приложение, скомпилированное под Any CPU из 32-х битного приложения, работаюего в режиме WOW64, ваше приложение также будет запущено в этом же 32-х битном режиме (рисунок 3).
Рисунок 3 – Запуск PowerShell.exe из 32-х битного планировщика
Теперь мы получаем аналогичную проблему, но уже вывернутую на изнанку: мы получаем BadImageFormatException при попытке использовать неуправляемую 64-х битную dll из 32-х битного процесса на 64-х битной операционной системе! Звучит неправдоподобно, но это факт! Причем самое интересное, что существует 32-х битная версия PowerShell.exe, которая располагается C:WindowsSysWOW64WindowsPowerShellv1.0, но вот «чистой» 64-х битной версии не существует.
Решение проблемы состоит в использовании дополнительного приложения, принудительно скомпилированного в режиме x64, которое будет запускаться из 32-х битного планировщика, и которое, в свою очередь, будет запускать PowerShell.exe в 64-х битном режиме (рисунок 4). Другим вариантом решения является использование утилиты CorFlags, которая может изменить информацию в заголовке исполняемого файла и заставить запускаться исполняемый файл в указанном формате. Однако эта славная утилита была найдена слишком поздно, и исправлять что-то на продакшне уже не было никакого желания.
Рисунок 4 – Запуск PowerShell.exe с помощью дополнительного приложения
Ну что ж, на сегодня все. Я надеюсь, что на практике вы не столкнетесь с подобными проблемами, а если и столкнетесь, то не будете под таким прессом времени и ответственности, под каким оказалась наша команда. Но, в любом случае, я надеюсь, что эта небольшая заметка сможет помочь вам решить проблемы запуска «управляемых» приложений под 64-х битными операционными системами, если такая проблема вдруг возникнет.
(*) Причина двух бессонных ночей была не только в этом, там получился целый ряд проблем, и эта – была лишь одной из них.
(**) Что это за планировщик и почему используется именно он, совершенно не важно, важно только то, что он оказался «чистым» 32-х битным приложением.
Несколько дополнительных ссылок
- 64-bit Applications
- Is this PowerShell Session a 32-bit or a 64-bit?
- Visual Studio .NET Platform Target Explained
Источник: sergeyteplyakov.blogspot.com