Unhandled Exception.... :'(
-
well the problem i m facing is a little strange.....:'( ... the problem occurs in VC provided class called CPushRoutingFrame...the function is Pop().... and the exception is Access violation.. It occurs occasionally and best part is in an empty destructor of one of my Window class. what could be the problem>>??? please help asap. shoaib Hell is full so i m back.... :)
-
well the problem i m facing is a little strange.....:'( ... the problem occurs in VC provided class called CPushRoutingFrame...the function is Pop().... and the exception is Access violation.. It occurs occasionally and best part is in an empty destructor of one of my Window class. what could be the problem>>??? please help asap. shoaib Hell is full so i m back.... :)
-
well the problem i m facing is a little strange.....:'( ... the problem occurs in VC provided class called CPushRoutingFrame...the function is Pop().... and the exception is Access violation.. It occurs occasionally and best part is in an empty destructor of one of my Window class. what could be the problem>>??? please help asap. shoaib Hell is full so i m back.... :)
Hi, Have a look @ the callstack window. It may give more information. Sujan
-
well the problem i m facing is a little strange.....:'( ... the problem occurs in VC provided class called CPushRoutingFrame...the function is Pop().... and the exception is Access violation.. It occurs occasionally and best part is in an empty destructor of one of my Window class. what could be the problem>>??? please help asap. shoaib Hell is full so i m back.... :)
well looking at the call stack window didnt helped me much...the full call stack contents are as follows: > mfc71ud.dll!CPushRoutingFrame::Pop() Line 759 + 0x3 C++ mfc71ud.dll!CFrameWnd::~CFrameWnd() Line 138 + 0xe C++ eOT802asud.dll!4c1445bf() eOT802asud.dll!4c142e70() eOT802asud.dll!4c133de8() ElxAppExtDevud.dll!ECEditorMDIChildWnd::~ECEditorMDIChildWnd() Line 36 + 0x20 C++ ElxVisualPpfaud.exe!ECWndChildFrame::~ECWndChildFrame() Line 79 + 0x44 C++ ElxVisualPpfaud.exe!ECWndChildFrame::`scalar deleting destructor'() + 0x2b C++ mfc71ud.dll!CFrameWnd::PostNcDestroy() Line 213 + 0x1f C++ mfc71ud.dll!CWnd::OnNcDestroy() Line 848 C++ mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012e7bc) Line 2023 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++ user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() esfl202asud.dll!4e065046() esfl202asud.dll!4e064d47() uxtheme.dll!5ad73c6e() uxtheme.dll!5ad71b71() esfl202asud.dll!4e064cea() user32.dll!77d43a68() user32.dll!77d4a8f9() user32.dll!77d4450d() user32.dll!77d4a15d() ntdll.dll!77fb4da6() user32.dll!77d4a191() user32.dll!77d6399b() user32.dll!77d639bd() user32.dll!77d626f6() user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() mfc71ud.dll!CWnd::DefWindowProcW(unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 1024 + 0x20 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=545, unsigned int wParam=2098868, long lParam=0) Line 1746 + 0x1a C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028a3c78, HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__
-
well looking at the call stack window didnt helped me much...the full call stack contents are as follows: > mfc71ud.dll!CPushRoutingFrame::Pop() Line 759 + 0x3 C++ mfc71ud.dll!CFrameWnd::~CFrameWnd() Line 138 + 0xe C++ eOT802asud.dll!4c1445bf() eOT802asud.dll!4c142e70() eOT802asud.dll!4c133de8() ElxAppExtDevud.dll!ECEditorMDIChildWnd::~ECEditorMDIChildWnd() Line 36 + 0x20 C++ ElxVisualPpfaud.exe!ECWndChildFrame::~ECWndChildFrame() Line 79 + 0x44 C++ ElxVisualPpfaud.exe!ECWndChildFrame::`scalar deleting destructor'() + 0x2b C++ mfc71ud.dll!CFrameWnd::PostNcDestroy() Line 213 + 0x1f C++ mfc71ud.dll!CWnd::OnNcDestroy() Line 848 C++ mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012e7bc) Line 2023 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++ user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() esfl202asud.dll!4e065046() esfl202asud.dll!4e064d47() uxtheme.dll!5ad73c6e() uxtheme.dll!5ad71b71() esfl202asud.dll!4e064cea() user32.dll!77d43a68() user32.dll!77d4a8f9() user32.dll!77d4450d() user32.dll!77d4a15d() ntdll.dll!77fb4da6() user32.dll!77d4a191() user32.dll!77d6399b() user32.dll!77d639bd() user32.dll!77d626f6() user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() mfc71ud.dll!CWnd::DefWindowProcW(unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 1024 + 0x20 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=545, unsigned int wParam=2098868, long lParam=0) Line 1746 + 0x1a C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028a3c78, HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__
Hi Shaoib, No Idea, But still have a look at the following link http://support.microsoft.com/default.aspx?scid=kb;EN-US;194300[^] Hoping that this may help you Sujan
-
well looking at the call stack window didnt helped me much...the full call stack contents are as follows: > mfc71ud.dll!CPushRoutingFrame::Pop() Line 759 + 0x3 C++ mfc71ud.dll!CFrameWnd::~CFrameWnd() Line 138 + 0xe C++ eOT802asud.dll!4c1445bf() eOT802asud.dll!4c142e70() eOT802asud.dll!4c133de8() ElxAppExtDevud.dll!ECEditorMDIChildWnd::~ECEditorMDIChildWnd() Line 36 + 0x20 C++ ElxVisualPpfaud.exe!ECWndChildFrame::~ECWndChildFrame() Line 79 + 0x44 C++ ElxVisualPpfaud.exe!ECWndChildFrame::`scalar deleting destructor'() + 0x2b C++ mfc71ud.dll!CFrameWnd::PostNcDestroy() Line 213 + 0x1f C++ mfc71ud.dll!CWnd::OnNcDestroy() Line 848 C++ mfc71ud.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012e7bc) Line 2023 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0) Line 1745 + 0x1e C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028dd658, HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__ * hWnd=0x002006b4, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0) Line 209 + 0x15 C++ user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() esfl202asud.dll!4e065046() esfl202asud.dll!4e064d47() uxtheme.dll!5ad73c6e() uxtheme.dll!5ad71b71() esfl202asud.dll!4e064cea() user32.dll!77d43a68() user32.dll!77d4a8f9() user32.dll!77d4450d() user32.dll!77d4a15d() ntdll.dll!77fb4da6() user32.dll!77d4a191() user32.dll!77d6399b() user32.dll!77d639bd() user32.dll!77d626f6() user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d45b40() user32.dll!77d45b5f() mfc71ud.dll!CWnd::DefWindowProcW(unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 1024 + 0x20 C++ mfc71ud.dll!CWnd::WindowProc(unsigned int message=545, unsigned int wParam=2098868, long lParam=0) Line 1746 + 0x1a C++ mfc71ud.dll!AfxCallWndProc(CWnd * pWnd=0x028a3c78, HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 241 + 0x1a C++ mfc71ud.dll!AfxWndProc(HWND__ * hWnd=0x00330542, unsigned int nMsg=545, unsigned int wParam=2098868, long lParam=0) Line 389 C++ mfc71ud.dll!AfxWndProcBase(HWND__
Looks like a useful call stack to me. Can't you just doubleclick on the pop statement within the call stack and have visual studio point you to the line of code in the software? If what you have shown me is the complete function, then I assume that one of the ASSERT inputs is evaluating to zero. I would have no idea why this would be but that is probably what is happening. Since I can't see your whole implementation and have no idea what a routing frame is used for in the context of your system, you'll have to research why pThreadState == NULL or why pThreadState->m_pPushRoutingFrame != this. One of those conditions is probably be causing the program to halt since that is the function you've shown me the crash occurs in. Simply assigning variables wouldn't cause a crash unless another thread within the system is trying to access the routing frame pointers while you are making the pointer swaps. This is another thing to look into. Since you obviously are using threads AND I don't see the use of a CMutex or CCriticalSection, you have to check and see if you have thread conflicts. Is it possible that the pop function is getting interrupted while you are reassigning the pointer values? Perhaps another thread is trying to use the pointer before the pop function is finished. But then if that were the case, I'd expect the debug crash to occur in another function or class. Weird; but swapping pointers like you are when running in a multithreaded system is very dangerous and the CCriticalSection and CMutex classes should be used to protect your software from erratic behavior. Regards, Shawn
-
Looks like a useful call stack to me. Can't you just doubleclick on the pop statement within the call stack and have visual studio point you to the line of code in the software? If what you have shown me is the complete function, then I assume that one of the ASSERT inputs is evaluating to zero. I would have no idea why this would be but that is probably what is happening. Since I can't see your whole implementation and have no idea what a routing frame is used for in the context of your system, you'll have to research why pThreadState == NULL or why pThreadState->m_pPushRoutingFrame != this. One of those conditions is probably be causing the program to halt since that is the function you've shown me the crash occurs in. Simply assigning variables wouldn't cause a crash unless another thread within the system is trying to access the routing frame pointers while you are making the pointer swaps. This is another thing to look into. Since you obviously are using threads AND I don't see the use of a CMutex or CCriticalSection, you have to check and see if you have thread conflicts. Is it possible that the pop function is getting interrupted while you are reassigning the pointer values? Perhaps another thread is trying to use the pointer before the pop function is finished. But then if that were the case, I'd expect the debug crash to occur in another function or class. Weird; but swapping pointers like you are when running in a multithreaded system is very dangerous and the CCriticalSection and CMutex classes should be used to protect your software from erratic behavior. Regards, Shawn
hi 2 all, well the issue is still not understood by me.... the only problem is that .... as far as my app being multithreaded is conserned i dont think thats an issue, the problem is as u must have seen, that the code crashes in a destructor... of CFrameWnd derived class...:'( well, as far as i get from my research this problem has something to do with dll's loading and thread states... well if any one know anything about it.... do reply asap.
-
hi 2 all, well the issue is still not understood by me.... the only problem is that .... as far as my app being multithreaded is conserned i dont think thats an issue, the problem is as u must have seen, that the code crashes in a destructor... of CFrameWnd derived class...:'( well, as far as i get from my research this problem has something to do with dll's loading and thread states... well if any one know anything about it.... do reply asap.
You never gave us the code for the destructor. Again, the call stack looks pretty plain to me. It's telling you exactly where the crash occurred. Without being able to look over your shoulder and step through your source code, there isn't a whole lot anyone else can do. IF it crashes in the destructor, why is the last call stack statement in the pop function?? My assumption is that the pop was where the crash occurred since that is where the program appears to have halted and this is the code fragment you gave us. While you are running in debug mode, are you able to step through the code right before the crash? WHen the system does crash, you should be able to double click on each statement in the call stack and perform an analysis of variable states; look for NULL pointers and test the assert conditions, etc. Consider yourself lucky to have a call stack that points directly at your code. Many times, you get call stacks that are pointing to MFC code which is really hard to troubleshoot. Shawn
-
You never gave us the code for the destructor. Again, the call stack looks pretty plain to me. It's telling you exactly where the crash occurred. Without being able to look over your shoulder and step through your source code, there isn't a whole lot anyone else can do. IF it crashes in the destructor, why is the last call stack statement in the pop function?? My assumption is that the pop was where the crash occurred since that is where the program appears to have halted and this is the code fragment you gave us. While you are running in debug mode, are you able to step through the code right before the crash? WHen the system does crash, you should be able to double click on each statement in the call stack and perform an analysis of variable states; look for NULL pointers and test the assert conditions, etc. Consider yourself lucky to have a call stack that points directly at your code. Many times, you get call stacks that are pointing to MFC code which is really hard to troubleshoot. Shawn
well i think i mentioned in one of my post that the code crashes some where IN THE MFC Code... the pop function i gave you was from afxpriv.cpp and it is an MFC file... one more thing as i mentioned back that the assert IS because of a NULL pointer... but i dont have a clue y its NULL.. cuz it have something to do with AFX_MANAGE_STATE... and shit like that... MSDN doesnt give any info about it... and again the best part is that it crashes occasionally..... not always... there is NO threads in my App. well i didnt get anything out of it... hope you can help me with AFX_MANAGE_STATE ....or something like that. as for your query... the last call at the stack is Pop cuz it is automatically called after a CFramewnd derived object is Destroyed using DeleteWindow which removes the current frame from the RoutingFrame stack. shoaib.