2016-07-01 10 views
2

Платформа Windows 7 SP1.Как идентифицировать исключение STATUS_INVALID_CRUNTIME_PARAMETER

Я недавно потратил некоторое время на отладку проблемы, вызванной тем, что код передавал недопустимый параметр одной из «безопасных» функций CRT. В результате мое приложение сразу же прервалось без предупреждения или чего-то еще - даже диалогового окна сбоя.

Сначала я попытался понять это, присоединив Windbg к моему приложению. Однако, когда произошел сбой, к моменту, когда код ворвался в Windbg, почти каждый поток был убит, кроме ОДНОГО потока, на который должен был проникнуть Windbg. Не было никакой подсказки относительно того, что было не так. Итак, я прикрепил Visual Studio в качестве отладчика, а когда мое приложение завершилось, я увидел, что каждый поток выходит с кодом ошибки 0xc0000417. То, что - это то, что дало мне понять, что где-то есть некорректная проблема.

Далее, как я пошел о попытке отладки это еще раз приложить Windbg к моему заявлению, но на этот раз в случайном порядке (путем проб & ошибок) место точек останова в различных местах, как kernel32!TerminateThread, kernel32!UnhandledExceptionFilter и kernel32!SetUnhandledExceptionFilter.

Из-за того, что место останова на SetUnhandledExceptionFilter сразу же показало стоп-сигнал оскорбительной нити, когда произошел сбой, и функцию CRT, которую мы вызывали неправильно.

Вопрос: Есть ли что-нибудь интуитивное, которое должно было мне сказать, чтобы сразу положить bp на SUEF? Я хотел бы понять это немного лучше и не делать этого методом проб и ошибок. Второй вопрос: w.r.t - код ошибки, который я определил через Visual Studio. Не прибегая к VS, как определить коды выхода потока на Windbg?

+0

I 'd использовать 'procdump -ma -e 1 -n 100 ', чтобы получить dumpfiles для каждого необработанного исключения, происходящего в вашем процессе. –

+1

Я не думаю, что это необходимо. Помогает ли 'sxe *'? (Или 'sxe 0xc0000417', если вы не хотите обрабатывать все переполнения с плавающей запятой) –

+0

Связанный: http://stackoverflow.com/questions/3467444/invalid-cruntime-parameter-itoa-s –

ответ

3

я собирался просто комментарий, но это стало больше, чтобы ответ

установка WinDbg в качестве посмертного отладчика, используя Windbg -I также маршрут всего необработанного исключения Windbg

Windbg -I должен зарегистрировать WinDbg в посмертном отладчике
по умолчанию Auto устанавливается в 1 в AeDebug Key Registry
, если вы не хотите, чтобы отладить все программы, вы можете изменить это 0
предоставить вам дополнительные возможности DoYouWanttoDebug в Wer Диалог

reg query "hklm\software\microsoft\windows nt\currentversion\aedebug" 

HKEY_LOCAL_MACHINE\software\microsoft\windows nt\currentversion\aedebug 
    Debugger REG_SZ "xxxxxxxxxx\windbg.exe" -p %ld -e %ld -g 
    Auto REG_SZ 0 

если вы зарегистрировали посмертных отладчик и запустить этот код

#include <stdio.h> 
#include <stdlib.h> 
int main (void) 
{ 
    unsigned long input[] = {1,45,0xf001,0xffffffff}; 
    int i = 0; 
    char buf[5] = {0}; 
    for(i=0;i<_countof(input);i++) 
    { 
     _ultoa_s(input[i],buf,sizeof(buf),16); 
     printf("%s\n",buf); 
    } 
    return 1; 
} 

на исключение вы увидите диалоговое окно Wer как этот

enter image description here

теперь вы можете выбрать для отладить эту программу

окна также записывают выход c ода на необработанное исключение в журнале событий

вы можете использовать PowerShell для извлечения одного события, как этот

PS C:\> Get-EventLog -LogName Application -Source "Application Error" -newest 1| format-list 


Index    : 577102 
EntryType   : Error 
InstanceId   : 1000 
Message   : Faulting application name: 
ultos.exe, version: 0.0.0.0, time stamp: 0x577680f1 
        Faulting module name: ultos.exe, version: 
0.0.0.0, time stamp: 0x577680f1 
        Exception code: 0xc0000417 
        Fault offset: 0x000211c2 
        Faulting process id: 0x4a8 
        Faulting application start time: 0x01d1d3aaf61c8aaa 
        Faulting application path: E:\test\ulto\ultos.exe 
        Faulting module path: E:\test\ulto\ultos.exe 
        Report Id: 348d86fc-3f9e-11e6-ade2-005056c00008 
Category   : Application Crashing Events 
CategoryNumber  : 100 
ReplacementStrings : {ultos.exe, 0.0.0.0, 577680f1, ultos.exe...} 
Source    : Application Error 
TimeGenerated  : 7/1/2016 8:42:21 PM 
TimeWritten  : 7/1/2016 8:42:21 PM 
UserName   : 

, и если вы хотите отлаживать

вы можете просмотреть CallStack

0:000> kPL 
# ChildEBP RetAddr 
00 001ffdc8 77cf68d4 ntdll!KiFastSystemCallRet 
01 001ffdcc 75e91fdb ntdll!NtTerminateProcess+0xc 
02 001ffddc 012911d3 KERNELBASE!TerminateProcess+0x2c 
03 001ffdec 01291174 ultos!_invoke_watson(
      wchar_t * expression = 0x00000000 "", 
      wchar_t * function_name = 0x00000000 "", 
      wchar_t * file_name = 0x00000000 "", 
      unsigned int line_number = 0, 
      unsigned int reserved = 0)+0x31 
04 001ffe10 01291181 ultos!_invalid_parameter(
      wchar_t * expression = <Value unavailable error>, 
      wchar_t * function_name = <Value unavailable error>, 
      wchar_t * file_name = <Value unavailable error>, 
      unsigned int line_number = <Value unavailable error>, 
      unsigned int reserved = <Value unavailable error>)+0x7a 
05 001ffe28 0128ad96 ultos!_invalid_parameter_noinfo(void)+0xc 
06 001ffe3c 0128affa ultos!common_xtox<unsigned long,char>(
      unsigned long original_value = 0xffffffff, 
      char * buffer = 0x001ffea4 "", 
      unsigned int buffer_count = 5, 
      unsigned int radix = 0x10, 
      bool is_negative = false)+0x58 
07 001ffe5c 0128b496 ultos!common_xtox_s<unsigned long,char>(
      unsigned long value = 0xffffffff, 
      char * buffer = 0x001ffea4 "", 
      unsigned int buffer_count = 5, 
      unsigned int radix = 0x10, 
      bool is_negative = false)+0x59 
08 001ffe78 012712b2 ultos!_ultoa_s(
      unsigned long value = 0xffffffff, 
      char * buffer = 0x001ffea4 "", 
      unsigned int buffer_count = 5, 
      int radix = 0n16)+0x18 
09 001ffeac 0127151b ultos!main(void)+0x52 
0a (Inline) -------- ultos!invoke_main+0x1d 
0b 001ffef8 76403c45 ultos!__scrt_common_main_seh(void)+0xff 
0c 001fff04 77d137f5 kernel32!BaseThreadInitThunk+0xe 
0d 001fff44 77d137c8 ntdll!__RtlUserThreadStart+0x70 
0e 001fff5c 00000000 ntdll!_RtlUserThreadStart+0x1b 
+0

Спасибо! К сожалению, хотя я уже пытался сделать Windbg отладчиком postmortem перед публикацией здесь. Это не помогло :-(Вы видите, что мы занимаемся написанием AddIns, которые запускаются в пространстве процессов Excel.exe. Даже если я настрою Windbg как AeDebug-ger, он разбивается, когда происходит сбой, но вызов стеки выглядят полностью фиктивными.Я даже пытался сделать procdump AeDebug-ger.Какими бы ни были дампы, которые он произвел таким образом, тоже не помогло. Установка 'bp' @' kernel32! SetUnhandledExceptionFilter' - единственное, что сработало. – ForeverLearning

+0

@Dilip: Excel может у вас есть обработчик обработанных исключений. Возможно, вы хотите спросить у SuperUser, как узнать, какие сбой AddIn и код исключения. –

+0

@ Dilip, если это сработало для вас, тогда я доволен, но настройка BreakPoint на SETUNHANDLEDEXCEPTIONFILTER - это то, что, как мне кажется, не может объяснить основная причина, связанная с тем, что все, что он делает, - это установить обратный вызов для вызова в случае любого необработанного исключения, это означает, что какой-то один (может быть, отличный или какой-то модуль просто устанавливает обработчик), так что это не означает, что исключение произошло, весь суф, кажется, был чем-то вроде миража – blabb