Ответ 1

Лично на терминале Linux я использую gcc для компиляции и gdb для отладки. Чтобы скомпилировать программу с параметрами отладки с помощью gcc, вам просто нужно добавить -g к другим флагам. Пример: gcc file.c -o file -std=c99 -g. Затем вы можете ввести gdb file и ввести интерактивный отладчик. Среди других полезных вещей вы можете запустить программу, вызвать функции и вставить точки останова. Для полного и хорошо объясненного использования перейдите на этот сайт - http://www.tutorialspoint.com/gnu_debugger/index.htm

Ответ 2

По крайней мере, в Visual Studio 2017 вы можете нажать CTRL + B и добавить _invalid_parameter останова функции в _invalid_parameter. Это остановит вашу программу в том месте, где сообщение было бы зарегистрировано, что позволит вам найти нарушающую функцию в стеке вызовов. Это будет работать, даже если кто-то другой код отменяет ваш вызов _CrtSetReportMode().

Ответ 3

Вещи, которые я узнал из этого вопроса (и это может помочь людям, которые ищут этот вопрос):

• Оказывается, эта ошибка может быть прослежена до строки кода, в которой говорится: бросить 1;
  Это означает, что это может быть просто неправильный код, ему даже не нужно быть функцией C, и ничто не должно быть неправильным с вашими параметрами. Поиск вашего кода и источника библиотек для "throw"
• Оказывается, что время ожидания на gdb не является индикатором чего-либо. Продолжайте попытки и повторите попытку, и, возможно, когда-нибудь вы сможете получить трассировку стека.

Ответ 4

Я столкнулся с тем же сообщением об ошибке "Invalid parameter..." при отладке драйвера Windows. Техника на этой странице, даже если для Windows, а не для адресации по этому вопросу, может оказаться полезной для тех, кто ищет это конкретное сообщение об ошибке. IOW HTH..

http://dennisyurichev.blogspot.com/2013/05/warning-invalid-parameter-passed-to-c.html

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

Ответ 5

Поскольку журнал выводится на консоль отладки, он должен сообщаться функцией OutputDebugStringA. Вы можете установить точку останова на функцию, чтобы увидеть, кто приводит к этому журналу. Чтобы установить точку останова на функцию, вы можете Ctrl+B в Visual Studio и ввести имя функции:

Но это может не сработать, или вы можете записать слишком много других сообщений, используя OutputDebugStringA. Обычно Invalid parameter passed to C runtime function, сообщается _invalid_parameter, поэтому вы также можете попытаться установить _invalid_parameter останова в функции _invalid_parameter. Это может работать не так хорошо, потому что из какой-то другой системной dll может быть сообщено, что ваш процесс ссылается на: ntdll.dll, KernelBase.dll и т.д. Чтобы установить KernelBase.dll останова на функцию, экспортируемую dll, вам необходимо использовать: <dll>!<exportname>:

_invalid_parameter
ntdll.dll!__invalid_parameter
KernelBase.dll!__invalid_parameter
msvcrt.dll!__invalid_parameter
ucrtbase.dll!__invalid_parameter

Все это разные функции, и вы можете увидеть их адреса:

В моем случае только когда я установил точку останова на ntdll.dll!__invalid_parameter я смог увидеть обратную трассировку, и сообщение журнала было вызвано winapi GetAdaptersAddresses. Точка останова на OutputDebugStringA оказалась бесполезной, потому что журнал был напечатан через API DbgPrint. Размещение точки останова на DbgPrint работает в этом случае.