Проблеммы среды или Windows
Как только я собираю чистый exe из проекта (выбрав соотв конфигурацию) и запускаю откомпилив и собрав решение то проект отрабатывает свои положенные действия! НО как только я запускю exe-шник отдельно, без среды, то он валиться!
У кого какие могут быть соображения?
Обычно, те кто поуменее, кхм, формулируют вопрос следующим образом "Под отладчиком программа работает нормально ...". А самые сообразительные - используют точки останова (breakpoint) - причем все это до того, как написать на форум.
Breakpoints в екзешнике? ну просвятите меня плиз как это сделать в уже скомпилинной и собранной проге...
2) иная рабочая директори -> не находит файлов
код многопоточный?
и пока телепаты в отпуске, может приведешь код?
Breakpoints в екзешнике? ну просвятите меня плиз как это сделать в уже скомпилинной и собранной проге...
ну так сделайте это прежде чем утверждать, что ваша "прога" "скомпиллина" и "собрана". Хотя в чем проблема и что мешает вам отлаживать екзешник - я честно говоря хз.
За одно так же не поленитесь - макросы assert, обращение к невалидным указателям и т.п. найдите в своей программе. телепатией тут мало кто владеет.
А DbgPrint не пробовали?
под словами "или нечто похожее" подобные функции имелись в виду :)
для того что бы воспользоваться DbgPrint нужно установить DDK. Есть другой способ вывода в окно Output в VS ?
для того что бы воспользоваться DbgPrint нужно установить DDK. Есть другой способ вывода в окно Output в VS ?
Для того, чтоб воспользоваться DbgPrint нужно установить Win32 API (Kernel32.dll) :D
OutputDebugString
Можно воспользоваться ATL/MFC-specific макросом TRACE(). В итоге он приведет к тому о чем говорит Green. Но в релиз-версии этот вызов будет удален.
OutputDebugString
OutputDebugString у меня заработал. Теперь буду им пользоваться :)
По поводу DbgPrint. Эта функция объявлена в ntddk.h котовый не входит в стандартную поставку. я прав? При чем тут Kernel32.dll?
По поводу DbgPrint. Эта функция объявлена в ntddk.h котовый не входит в стандартную поставку. я прав? При чем тут Kernel32.dll?
При том, что DbgPrint я подразумеваю ф-ции, которые работают через OutputDebugString, которая в свою очередь находиться в kernel32.
Не нужно устанавливать ddk, чтоб ею воспользоваться. Можно использовать тот же OutputDebugString, TRACE или написать свою обертку, если это действительно надо.
[QUOTE=MSDN]Only kernel-mode drivers can call the DbgPrint routine.[/QUOTE]
отладки драйверов
Мессажбоксы, выстреливающие изнутри цикла, заполняющие экран со скоростью пулеметной очереди? Что за бред!
Используйте запись в лог файл + пошаговую отладку с просмотром значений всех переменных и прочее.
отладки драйверов
А у меня с точным именем DbgPrint находится в файле собственного написания, сделано через OutputDebugString и используется в User-Mode.
Пардон, что сразу не привел Win32 API ф-цию,которая она использует, но исправился ниже.
Сути дела это не меняет - есть способ выводить в debug output и не использовать MessageBox.
Используйте запись в лог файл + пошаговую отладку с просмотром значений всех переменных и прочее.
Ну что вы прям налетели... я просто предложил один из вариантов, который требует написания не много дополнительного кода....
По поводу пошаговой отладки.... вопрос был в том что необходимо тестировать программу без использования IDE.
По поводу пошаговой отладки.... вопрос был в том что необходимо тестировать программу без использования IDE.
Тестирование и отладка - это разные вещи. Тестирование (юнит) выполняется при помощи юнит-тестов с ассертами в нужных местах. И запускаться эти тесты могут откуда угодно - из IDE, из консоли, из сервисы непрерывной интеграции - откуда угодно.
А вот отлаживать - лучше в IDE, да. В хороших IDE очень много очень полезных возможностей для отладки.
Ну, во-первых же, мир не ограничивается VS. И хочется (возможно я плохо выразился) именно профессионального "книжного" обозрения всех возможностей. MSDN для меня слишком сух и да, действительно, порой неполон.
Он как бы охренительно неполон, например касаемо драйверов. :rolleyes: