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

Мое программное обеспечение недавно было развернуто на клиенте, который сказал, что приложение зависало сразу после его запуска. После некоторой начальной отладки клиент предоставил мне удаленный доступ к одному из компьютеров, на котором не удалось запустить приложение. Я обнаружил, что сбой не был характерен для моего приложения. Любое приложение, которое зависело от .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).

DotNetFatalExecutionErrorScreenshot
(источник: blakerobertson.com )

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

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

Ответы [ 14 ]

0 голосов
/ 24 сентября 2009

Запустите его с помощью WinDbg. Используя Son of Strike, вы сможете точно понять, почему он падает. Может быть ошибка загрузки низкого уровня сборки. В прошлом я сталкивался с подобными проблемами, используя WinDbg.

0 голосов
/ 22 сентября 2009

Еще пара предложений:

  • Просто чтобы убедиться, что это не проблема vshost.exe, я бы попробовал запустить MyProcess.exe в cdb / windbg и посмотреть поведение.
  • Проблема выглядит как чтение AV, и если приложение работает должным образом в отладчике, я бы попытался восстановить мою установку .Net, в случае возможного повреждения способа выполнения операционной системой сборки .Net сборки .NET для mscorwks .dll.
0 голосов
/ 22 сентября 2009

Исправления для серебряной пули нет, и я не думаю, что это проблема разрешения.

Вот что я бы попробовал

  1. Если это 64-битная машина, попробуйте перейти в 32-битный режим. Я видел это с 32-битными библиотеками, которые пытались работать в 64-битной версии.
  2. Создайте новый веб-сайт на сервере и запустите на нем aspnet_regiis.
  3. Удалите и переустановите фреймворки 2.0 и 3.5. заверши и запусти aspnet_regiis после завершения
0 голосов
/ 22 сентября 2009

Звучит так, будто ты получил "веселое" место. Понятия не имею, но в любом случае, вот мои предложения, пронизывающие карму и проникающие в темноту.

1) В дополнение к обычным пользовательским разрешениям, назначаемым Windows, существует также отдельный набор параметров безопасности специально для .NET Framework. Если у вас установлен .NET SDK, найдите инструмент «Конфигурация Microsoft .NET Framework» на панели управления (может быть в разделе «Администрирование»). Посмотрите, не отличается ли какая-либо из настроек от вашей машины разработчика.

2) Я предполагаю, что ваш клиент находится под контролем ИТ-режима на своем рабочем месте. Посмотрите, сможете ли вы или ваш клиент получить новую установку Windows для работы программы, а затем, работая со своей ИТ-группой, применить одно из их требований (параметры безопасности, антивирусные программы и т. Д.) За один раз до остановки вашей программы. за работой. Старый добрый прошлый рабочий поиск ошибок. Конечно, это предполагает сотрудничество с его ИТ-отделом, поэтому я надеюсь, что ваша программа где-то важна для руководителя.

...