Что может вызвать немедленное падение ЛЮБОГО приложения .NET ... кроме проекта, который я создаю и отлаживаю в Visual Studio?

Question

Мое программное обеспечение недавно было развернуто на клиенте, который сказал, что приложение зависало сразу после его запуска. После некоторой начальной отладки клиент предоставил мне удаленный доступ к одному из компьютеров, на котором не удалось запустить приложение. Я обнаружил, что сбой не был характерен для моего приложения. Любое приложение, которое зависело от .NET Framework, немедленно прекращало работу.

Удобно было установить Visual Studio 2008, поэтому я создал приложение «Hello World» и нажал «Отладка». Приложение работало нормально. Но затем, когда я попытался выполнить сгенерированные двоичные файлы в каталоге /bin/Debug/HelloWorld.exe за пределами Visual Studio, произошел сбой.

Список вещей, которые я пробовал (ОБНОВЛЕНО) :

• Я проверил, что «Все» имеет разрешения на чтение и выполнение для c: \ Windows.
• Чтобы проверить, что проблема была в .NET Framework (а не в моем приложении), я попытался загрузить Paint .NET на компьютеры. Интерфейс установки завис так же.
• Выполнил ремонт .NET Framework, как описано в http://support.microsoft.com/kb/908077 (Мальчик был таким забавным и отнимал много времени). Не повезло.
• Установлен .NET 3.5 SP1 (до этого только .NET 3.5) Примечание: мое приложение нацелено на 2.0, так что я сделал это больше в долгосрочной перспективе ... но я понял, что .NET 3.5 SP1 также обновляет базовый рамки.
• Ran Инструмент проверки установки .NET Аарона Стебнера . Этот инструмент показал, что .NET был успешно установлен. (Я забыл, проверил ли я все версии, но по крайней мере 2.0 работал).
• Протестировано несколько приложений mini hello world, предназначенных для .NET 2.0 и .NET 3.5, и оба зависали одинаково.
• Попытка запуска приложений .NET через линию windbg cmd. Это позволило мне вызвать мои простые приложения hello world. Итак, простой .NET hello world работает, когда вызывается windbg или запускается через debug в visual studio ... но не работает, если я пытаюсь выполнить его автономно.

Я создал файл дампа, используя WinDbg. Это было не так уж и откровенно для меня.

FAULTING_IP:  mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010        test    byte ptr [eax+10h],10h

EXCEPTION_RECORD:  0012f710 -- (.exr 0x12f710) ExceptionAddress: 79f4ff9d (mscorwks!PEImage::GetEntryPointToken+0x00000021) ExceptionCode: c0000005 (Access violation)   ExceptionFlags: 00000000 NumberParameters: 2    Parameter[0]: 00000000    Parameter[1]: 00000010 Attempt to read from address 00000010

FAULTING_THREAD:  00000b44
PROCESS_NAME:  MyProcess.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid    
DETOURED_IMAGE: 1    
NTGLOBALFLAG:  0    
APPLICATION_VERIFIER_FLAGS:  0    
MANAGED_STACK: !dumpstack -EE OS Thread Id: 0xb44 (0) Current frame:  ChildEBP RetAddr  Caller,Callee

EXCEPTION_OBJECT: !pe cb10b4 Exception object: 00cb10b4 Exception type: System.ExecutionEngineException Message: <none> InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 80131506    
MANAGED_OBJECT_NAME:  System.ExecutionEngineException    
CONTEXT:  0012f72c -- (.cxr 0x12f72c) eax=00000000 ebx=00000000 ecx=00000000 edx=0000000e esi=001a1490 edi=00000001 eip=79f4ff9d esp=0012f9f8 ebp=0012fa1c iopl=0         nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246 mscorwks!PEImage::GetEntryPointToken+0x21: 79f4ff9d f6401010        test    byte ptr [eax+10h],10h     ds:0023:00000010=?? Resetting default scope    
READ_ADDRESS:  00000010     
FOLLOWUP_IP:  mscorwks!PEImage::GetEntryPointToken+21 79f4ff9d f6401010        test    byte ptr [eax+10h],10h    
BUGCHECK_STR:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN    
PRIMARY_PROBLEM_CLASS:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN
    DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN    
LAST_CONTROL_TRANSFER:  from 79ef02b5 to 79f4ff9d    
STACK_TEXT:   79f4ff9d mscorwks!PEImage::GetEntryPointToken+0x21 79ef02b5 mscorwks!PEFile::GetEntryPointToken+0xa0 79eefeaf mscorwks!SystemDomain::ExecuteMainMethod+0xd4 79fb9793 mscorwks!ExecuteEXE+0x59 79fb96df mscorwks!_CorExeMain+0x15c 7900b1b3 mscoree!_CorExeMain+0x2c 7c817077 kernel32!BaseProcessStart+0x23    

SYMBOL_STACK_INDEX:  0    
SYMBOL_NAME:  mscorwks!PEImage::GetEntryPointToken+21    
FOLLOWUP_NAME:  MachineOwner    
MODULE_NAME: mscorwks    
IMAGE_NAME:  mscorwks.dll    
DEBUG_FLR_IMAGE_TIMESTAMP:  471ef729    
STACK_COMMAND:  .cxr 0012F72C ; kb ; dds 12f9f8 ; kb    
FAILURE_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_80000003_mscorwks.dll!PEImage::GetEntryPointToken    
BUCKET_ID:  APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_SHUTDOWN_DETOURED_mscorwks!PEImage::GetEntryPointToken+21    
WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/MyProcess_exe/2_4_4_39/4a8a192c/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1

Followup: MachineOwner

Редактировать 1: Подробности журнала событий для этой ошибки говорят, что это .NET Runtime версия 2.0.50727.3053 - Неустранимая ошибка механизма выполнения (7A097706) (80131506).

_{(источник: blakerobertson.com )}

Редактировать 2 (10-7-09): эта проблема все еще активна.

Редактировать 3 (3-29-10): Это обновление должно сообщить всем, что я никогда не решал проблему успешно. Клиент, который это сделал, потерял интерес к его решению и просто перезаписал машину :(. Спасибо за все вклады.

Answer 1

Судя по вашим выводам windbg, похоже, что кто-то внедрил DLL в процесс при запуске процесса, и что это внедрение не предназначено для какой-либо загруженной версии mscorwks. Если это обычная рабочая станция (например, секретарь), я бы конфисковал ее для MIS / IT для проверки на наличие вредоносных программ. Если это машина, расположенная в серверной комнате, я бы посоветовал клиенту выполнить перемещение на другую машину.

Я не подозреваю, что это случится с любым другим клиентом, и через 8 лет разработки .NET единственное, что может (как ожидается) вызвать поведение, которое вы описываете, это попытка запустить приложение .NET в системе. с установленной более старой версией фреймворка (например, отсутствие поддержки, приводит к появлению стандартного диалога отладки / отмены в большинстве версий Windows), и это НЕ та проблема, которая есть. Это также не связано с архитектурой процессора, версией платформы или уровнем SP, оно не связано ни с коммерческим программным обеспечением AV, ни с коммерческим программным обеспечением для обеспечения безопасности сети.

Это явно не что-то в вашем коде, и я не вижу, чтобы это можно было исправить для вашего клиента. Я не знаю ни инструмента, ни серии шагов, которые вы можете использовать для решения этой проблемы, за исключением того, что заказчик заново изобразил целевой компьютер. Прежде чем они это сделают, MIS / IT снова предоставит их для обнаружения потенциальных вредоносных программ (в частности, вредоносных программ, которые не будут распространяться среди широкой общественности).

Для соответствующего прочтения: http://research.microsoft.com/apps/pubs/default.aspx?id=68568

Удачи.

Answer 2

Несколько членов нашей команды недавно столкнулись с той же проблемой, и они обнаружили, что после удаления Embassy Trust Suite с помощью Wave System все нормализовалось. Следующая ссылка привела к ответу.

http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/6e6b8496-c1f1-4fc9-bcc9-2129a6329804/

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

Answer 3

Недавно у меня возникла та же проблема, и я выполнил эти шаги Сбой приложения Microsoft .NET , и это исправило сбой приложения .NET без цели

Answer 4

Была такая же проблема, и она была исправлена ​​с помощью мастера публикации. Вот как я узнал, что на целевом компьютере не установлен пакет Visual Basic Powerpack 3.0. После установки он работает как шарм.

Answer 5

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

Answer 6

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

Удаление всех временных файлов во временной папке .net (а также проверка разрешения этой папки)

Answer 7

У меня недавно была проблема, которая проявлялась очень похожим образом. Оказалось, что некоторые сторонние библиотеки DLL не были частью моего развертывания (я просто копировал вещи из каталога bin). Я создал установочное приложение, которое подобрало все библиотеки DLL, и как только они были правильно развернуты, оно перестало падать. Странно, что это был тяжелый провал, а не исключение.

Это может не относиться к вам, поскольку вы говорите, что оно применимо к любому приложению .NET. Может быть, вы работаете в старом файле проекта с некоторыми оставшимися ссылками?

Answer 8

Может быть, эта ссылка может помочь вам решить вашу проблему Исправление ошибки «.NET Runtime version 2.0.50727.3053 - Неустранимая ошибка механизма выполнения» [.NET] .

Какую операционную систему (Windows XP, Vista и т. Д.) Установил компьютер ваших клиентов?

Вы пытались полностью удалить .NET Framework (не восстанавливать), а затем переустановить его?

Answer 9

Поскольку это происходит не на каждой клиентской машине, может ли это быть ОЗУ? Вы можете перезагрузить неисправный компьютер и запустить инструмент диагностики памяти?

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

Answer 10

Убедитесь, что пользователь не запускает приложение из общего сетевого ресурса. По умолчанию .Net выдает исключение безопасности при попытке запустить приложение из ненадежного источника.

Это поведение можно изменить с помощью служебной программы настройки Microsoft .Net Framework в разделе «Администрирование».