0xC000041D: An unhandled exception was encountered during a user callback.
-
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes. The message type is always 874(x36A). The only true call backs I have are for custom draw list boxes and typically when I have an error in those routines MFC catches and breaks at that point. Obviously that are countless other messages processed. I am trying to determine A: what is message 874? and B: what circumstances cause it to be posted (though A may answer B)?
-
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes. The message type is always 874(x36A). The only true call backs I have are for custom draw list boxes and typically when I have an error in those routines MFC catches and breaks at that point. Obviously that are countless other messages processed. I am trying to determine A: what is message 874? and B: what circumstances cause it to be posted (though A may answer B)?
-
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes. The message type is always 874(x36A). The only true call backs I have are for custom draw list boxes and typically when I have an error in those routines MFC catches and breaks at that point. Obviously that are countless other messages processed. I am trying to determine A: what is message 874? and B: what circumstances cause it to be posted (though A may answer B)?
Message
0x036AisWM_KICKIDLE(defined in afxpriv.h). It is a private MFC message used to update the UI (e.g. menu items, tool bar buttons and the status bar). So you might check your UI update handlers if one of those is the error source. -
Message
0x036AisWM_KICKIDLE(defined in afxpriv.h). It is a private MFC message used to update the UI (e.g. menu items, tool bar buttons and the status bar). So you might check your UI update handlers if one of those is the error source.Thanks - I must have been too tired to figure that one out.
-
I cannot find the specific message number in Winuser.h in VS 2013, but I did find the following two lines:
#define WM_AFXFIRST 0x0360
#define WM_AFXLAST 0x037FGoogling for
WM_AFXFIRSTcame up with: WM_AFXFIRST - Google Search[^].Thanks - I found those two - Jochen below narrowed it down.
-
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes. The message type is always 874(x36A). The only true call backs I have are for custom draw list boxes and typically when I have an error in those routines MFC catches and breaks at that point. Obviously that are countless other messages processed. I am trying to determine A: what is message 874? and B: what circumstances cause it to be posted (though A may answer B)?
Austin Donaghy wrote:
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes.
There is a good essay of Joe Newcomer: Debug vs. Release[^] I'd recommend to check it out!
-
This break in CWnd::WindowProc randomly appears when running my application(originally released in 2010 and runs 24/7 in many places) in debug. In release mode it crashes. The message type is always 874(x36A). The only true call backs I have are for custom draw list boxes and typically when I have an error in those routines MFC catches and breaks at that point. Obviously that are countless other messages processed. I am trying to determine A: what is message 874? and B: what circumstances cause it to be posted (though A may answer B)?
99% of the time if you get a difference between release and debug mode you forgot to zero a variable and assume it is. Turn the warning levels up to full and you should get a warning saying "use of uninitialized variable". Usually it is something like this
int Bad (int someval){
int i;
if (someval > 0){
i = 1;
}
if (i == 0) return (1);
return (0);
}In debug mode all local variables are zeroed automatically. That simply doesn't happen in release mode the variables will start at whatever rubbish was in the stack at the position it was allocated. In the above code the behaviour of "bad" is totally predictable in debug mode as "i" will always start at 0. In release mode you have no idea what is going to happen as "i" could start at any value and the return is purely chance based. Look carefully at the code, now try compiling it and tell me if you get a warning :-)
In vino veritas