Right way to debug unhandled exception in MS Visual C++

Question

What is the right way to debug an unknown unhandled exception in Microsoft Visual Studio C++ (native c++, Visual Studio 2015).
Today I have received the exceptions (the text: Exception thrown: read access violation. this was 0x4.):

The code what is shown after press the "Break" button is just a code from standard Qt framework header qscopedpointer.h:

Now I have no idea what is the reason of this issue. Usually it was no problem, but know I have run the project that always correct ran in VS 2012, and now I am not even sure whether this is a real error or I need just to uncheck the "Break when this exception type is thrown".

I cannot "Step out" from the point, and looking the call stack also does not give understanding of the issue:

the text:

Qt5Cored.dll!QScopedPointer<QObjectData,QScopedPointerDeleter<QObjectData> >::data() Line 135   C++
    Qt5Cored.dll!qGetPtrHelper<QScopedPointer<QObjectData,QScopedPointerDeleter<QObjectData> > >(const QScopedPointer<QObjectData,QScopedPointerDeleter<QObjectData> > & p) Line 1014   C++
    Qt5Cored.dll!QWinOverlappedIoNotifier::d_func() Line 60 C++
    Qt5Cored.dll!QWinOverlappedIoNotifier::waitForAnyNotified(int msecs=1) Line 358 C++
    Qt5SerialPortd.dll!QSerialPortPrivate::waitForNotified(int msecs=1) Line 588    C++
    Qt5SerialPortd.dll!QSerialPortPrivate::waitForReadyRead(int msecs=1) Line 251   C++
    Qt5SerialPortd.dll!QSerialPort::waitForReadyRead(int msecs=1) Line 1309 C++
    MyProject.exe!UsualSep::send_cmd_and_receive_answer(const QByteArray & ba={...}, QByteArray & ans={...}, int nread=2) Line 797  C++
    MyProject.exe!UsualSep::isAvailable(bool & avbl=false) Line 204 C++
    MyProject.exe!UsualSep::on_workThread_started() Line 80 C++
    MyProject.exe!QtPrivate::FunctorCall<QtPrivate::IndexesList<>,QtPrivate::List<>,void,void (__thiscall UsualSep::*)(void)>::call(void(UsualSep::*)() f=0x00eb172b, UsualSep * o=0x007838d8, void * * arg=0x02bff91c) Line 501    C++
    MyProject.exe!QtPrivate::FunctionPointer<void (__thiscall UsualSep::*)(void)>::call<QtPrivate::List<>,void>(void(UsualSep::*)() f=0x00eb172b, UsualSep * o=0x007838d8, void * * arg=0x02bff91c) Line 520    C++
    MyProject.exe!QtPrivate::QSlotObject<void (__thiscall UsualSep::*)(void),QtPrivate::List<>,void>::impl(int which=1, QtPrivate::QSlotObjectBase * this_=0x029ee9d8, QObject * r=0x007838d8, void * * a=0x02bff91c, bool * ret=0x00000000) Line 143   C++
    Qt5Cored.dll!QtPrivate::QSlotObjectBase::call(QObject * r=0x007838d8, void * * a=0x02bff91c) Line 124   C++
    Qt5Cored.dll!QMetaObject::activate(QObject * sender=0x029ee9a0, int signalOffset=3, int local_signal_index=0, void * * argv=0x00000000) Line 3720   C++
    Qt5Cored.dll!QMetaObject::activate(QObject * sender=0x029ee9a0, const QMetaObject * m=0x670e5db0, int local_signal_index=0, void * * argv=0x00000000) Line 3595 C++
    Qt5Cored.dll!QThread::started(QThread::QPrivateSignal __formal={...}) Line 156  C++
    Qt5Cored.dll!QThreadPrivate::start(void * arg=0x029ee9a0) Line 384  C++
    ucrtbased.dll!774f8968()    Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll] 
    ucrtbased.dll!774f867b()    Unknown
    kernel32.dll!74fc336a() Unknown
    ntdll.dll!77169902()    Unknown
    ntdll.dll!771698d5()    Unknown

And my main question is not about what to do in this particular case, but what is the general way to debug such exceptions.

Answer 1

If the exception has a handler somewhere in the call stack it might be ok to let it continue regardless. However, have sa look to make sure you understand what is going on.

If the call stack points to you code, start there. I presume, in this case, "MyProject.exe!UsualSep::send_cmd_and_receive_answer..." How does this end up trying to get the data d? here do you think you set this?

My general approach would be to to try to narrow down the problem to a small self-contained function and wrap it up in a test which you can run automatically which repeats the problem. Then try to fix it. Maybe you need to try isNull as a check somewhere in your code?

Answer 2

If you check "break when this exception type is thrown" then I would guess that on the next debug run, you will get the debugger opening at the point the exception is thrown, which might well tell you the problem.

If you handle the exception of course it is no longer necessarily a bug. You can debug with some difficulty by handling the exception in a try block in main, then drilling down to work out exactly which portion of the program throws it.

There could be a bug in Qt rather than your own code. If so it's likely to be something quite obscure - Qt is tested for most general real world use - but it will be hard to find. However the stack trace suggests that your function send_cmd_and_receive_answer() is at fault. Most likely it's calling Qt with memory it does not own, or in other words passing it a wild pointer.