@BioNicle12

Доброго времени суток, в с++ я пока только осваиваю азы и т.п.

Серверное приложение для не особо сложных манипуляций, но написано не мной, я только пытаюсь разбираться в коде), недавно заметил такую странность, если через браузер попытаться подключиться к ее открытому порту, то на одном ПК с вин2008 программа выдает ошибку, мол неизвестный пакет и рушится. Попробовал на тестовом ПК вин7, просто выдает туже ошибку, но продолжает дальше работать.

Вопрос такой, отчего на вин2008 программа крошится и как можно выяснить причину, дабы потом ее устранить, может есть какой софт в помощь.

0

@lemegeton

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

Таким образом, с тем же успехом после браузера можно разбираться, почему падает SSH клиент, натравленный на порт этого приложения, а затем VPN-клиент, а потом можно взяться за Х-ы или ICQ.
Вы собираетесь устранить падения ВСЕХ приложений при подключении к вашему приложению? Даже тех, которые еще только выйдут?

0

Убежденный

1) Запустить программу под отладчиком.

Способ настолько очевидный, что комментариев не требует.
Цеплять отладчик к службе, кстати, можно с помощью ключа реестра
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

2) Организовать в программе нормальную проверку и обработку ошибок.

Это значит, что всякое возвращаемое значение обязательно должно проверяться и
обрабатываться надлежащим образом. Если что-то выходит за пределы "контракта" -
лучше сразу реагировать наиболее строгим образом, вплоть до аварийного
завершения программы. Это позволяет еще на ранних этапах отлавливать многие
ошибки, которые в иных условиях остались бы незамеченными.
Информация об ошибке должна быть максимально детальной - имя функции/класса,
причина ошибки, код выхода, LastError и т.д.

3) Реализовать логгирование/трассировку.

Даже в простейшем виде (запись в текстовый файл) это приносит ощутимую
пользу и позволяет увидеть, что там на самом деле происходит, за "кулисами".

4) Обложить все тестами, с ног до головы.

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

5) Реализовать в программе систему сбора крэш-дампов и "обратной связи".

Например, можно поставить обработчик исключений (SetUnhandledExceptionFilter), а
при возникновении исключения записать крэш-дамп процесса (MiniDumpWriteDump).
Отладочные символы, сгенерированные при построении программы (.pdb), нужно сохранить.
Позже такой крэш-дамп можно открыть в отладчике (WinDbg, например) и разобрать с
нужной детальностью, что именно произошло и почему. Есть, кстати, готовые библиотеки
под это дело:

CrashRpt
http://code.google.com/p/crashrpt

breakpad
http://code.google.com/p/google-breakpad

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

1