Использую Microsoft visual studio 2008. Сейчас столкнулся со следущей проблемой:

1) Я компилирую приложение в Debug режиме

2) Происходит unhandled exception при работе моего приложения( не сразу, через мин 20), без указания
причины ошибки, просто написано, что unhandled exception в Имя_моего_проекта.vsln и больше ничего

3) *.pdb файл в папке с exe присутствует.

4) Никакого указания на строку, где произошла ошибка нет( если не считать ассемблер-строку)

Помогите разобраться пожалуйста

Это ошибка win32. Я юзаю в своём проекте win32 функции, поэтому скорее всего дело в том, что это неуправляемый код. Что делать в таком случае?

у вас .NET4 ? Тогда будьте вкурсе что ошибки типа AccessViolation более не ловятся в нём даже catch{} конструкцией.
Для того чтобы включить режим совместимости с .NET 3.5 надо в app.config прописать:
но вообще это нерекомендуемо (подробнее об настройке: http://www.marklio.com/marklio/PermaLink,g...900e451f9.aspx)

Дело в том, что впринципе восстановить благополучное состояние после таких ошибок невозможно - это низкоуровневая ошибка, которая в любом случае должна вызывать креш программы.

А для того чтобы понять в чем конкретно ошибка надо взять winDBG, запуститься с SOS.DLL и юзать нечто вроде !VerifyHeap -v совместно с !ListNearObj наверно...

jonie , нет у меня 3.5. 

А насчёт: "надо взять winDBG, запуститься с SOS.DLL и юзать нечто вроде !VerifyHeap -v совместно с !ListNearObj". Интересно. Надо попробовать поразбираться

Это сообщение отредактировал(а) lightforever - 10.5.2011, 17:42

А неподскажите какие ошибки не ловятся в try , catch в Netframework 3.5? Ато не найду

lightforever, не ошибки, а языковые исключения cath-ем ловятся только.... другой вопрос что CLR 3.5 преобразует AccessViolation (это native исключения, они, кстати, не ловятся и в Сях например) в языковые...
Но, некоторые эта штука не словит. В частности ошибки компиляции байткода кода, например: MethodNotFoundException (тоже ошибка компиляции) или вообще косячный код.

Насчет Native ошибок  фих его знает.. можно, наверно, глянуть в сорцы CLR на этот счет (но они не все открыты) ...

и еще: то что у вас 3.5 вовсе не значит что программа работает под CLR 3.5 .. запустите clrver -all чтобы узнать что реально используется.

Это сообщение отредактировал(а) jonie - 10.5.2011, 21:35