Najpierw zbuduj projekt w trybie przyjaznym debugowaniu, czyli z symbolami debuggera oraz bez agresywnych optymalizacji, a następnie odpal program z poziomu IDE, czyli z działającym debuggerem. Kiedy program spowoduje jakikolwiek błąd (runtime error lub exception), to wyskoczy okienko błędu z informacją o tym w czym tkwi problem, a po jego zamknięciu IDE podświetli linijkę w kodzie, która błąd spowodowała.
Wykonanie programu cały czas będzie wstrzymane, więc będziesz mógł użyć narzędzi debuggera do sprawdzenia np. zmiennych, parametrów, call stacku itd., a dzięki nim zawsze masz możliwość znalezienia przyczyny w kilka sekund. Jeśli chcesz sprawnie uprawiań programowanie i likwidować istniejące w nim błędy, to poświęć jeden wieczór i pobaw się ficzerami debuggera w IDE. Bez jego znajomość, szukanie błędów będzie trudne i czasochłonne.
Natomiast kiedy będziesz potrzebował skompilować release dla ludzi, to użyj buildu bez symboli debuggera i bez ficzerów przydatnych do debugowania (testowania zakresów, asercji, czyszczenia pamięci zmiennych itd), a także z agresywnymi optymalizacjami.
jeśli to bardzo rzadki wyjątek […]
Access Violation to bardzo częsty wyjątek i dytyczy odwołania się do nieprzydzielonej procesowi pamięci. Powodowany jest albo przez dereferencję znil
owanego wskaźnika lub referencji, albo podczas dereferencji wskaźnika lub referencji obiektu, które wskazują na zwolniony blok pamięci lub zwolniony obiekt.