access violations
-
Hi, I am experiencing some strange problems. I am getting a whole bunch of access violations when I run my program. The program doesn't crash but in the debug window you can see about 200 access violation messages. I tracked this down to CMainFrame::OnCreate(). Infact, all of these access violations occur at the point where the CToolBar's CreateEx function get called. Here is what App Wizard created for my project for the CToolBar, if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME)) { TRACE0("Failed to create toolbar\n"); return -1; // fail to create } The Toolbar get created, but with a whole bunch of access violations along the way. Another thing, this doesn't happen all the time. I would guess three out of five times I run the program, I get all of these access violations. Anyway, I hope someone know why this is happening. I would really appreciate the help. Just in case someone was interested, here is a look at what the violation message looks like First-chance exception in Plas.exe (GDI32.DLL): 0xC0000005: Access Violation. Thanks
-
Hi, I am experiencing some strange problems. I am getting a whole bunch of access violations when I run my program. The program doesn't crash but in the debug window you can see about 200 access violation messages. I tracked this down to CMainFrame::OnCreate(). Infact, all of these access violations occur at the point where the CToolBar's CreateEx function get called. Here is what App Wizard created for my project for the CToolBar, if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME)) { TRACE0("Failed to create toolbar\n"); return -1; // fail to create } The Toolbar get created, but with a whole bunch of access violations along the way. Another thing, this doesn't happen all the time. I would guess three out of five times I run the program, I get all of these access violations. Anyway, I hope someone know why this is happening. I would really appreciate the help. Just in case someone was interested, here is a look at what the violation message looks like First-chance exception in Plas.exe (GDI32.DLL): 0xC0000005: Access Violation. Thanks
I don't know if this is the case, but I experieced some problems with AppWizard generated applications if they had a Toolbar but not a StatusBar, because even if I unselected the StatusBar in the Wizard page, some generated code still made use of it. Don't know why, but it's true. It seems, however, that your problem is a little different. You wrote of the toolbar creation, so I thought of my past troubles with it. Cheers, Paolo
-
Hi, I am experiencing some strange problems. I am getting a whole bunch of access violations when I run my program. The program doesn't crash but in the debug window you can see about 200 access violation messages. I tracked this down to CMainFrame::OnCreate(). Infact, all of these access violations occur at the point where the CToolBar's CreateEx function get called. Here is what App Wizard created for my project for the CToolBar, if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME)) { TRACE0("Failed to create toolbar\n"); return -1; // fail to create } The Toolbar get created, but with a whole bunch of access violations along the way. Another thing, this doesn't happen all the time. I would guess three out of five times I run the program, I get all of these access violations. Anyway, I hope someone know why this is happening. I would really appreciate the help. Just in case someone was interested, here is a look at what the violation message looks like First-chance exception in Plas.exe (GDI32.DLL): 0xC0000005: Access Violation. Thanks
I am surprised that your program continues to run after an access violation. Perhaps VC 6 has something new for debugging that allows a program to continue execution in spite of an access violation; if so, I would not know about it since I still use VC 5. You might check to see if it is possible to get the debugger to stop when an access violation occurs. If you can do that then you can look at the stack and you might get a good indication of the problem. Are you sure you are working with a debug version of your program? You should, if you are getting errors like that.
-
I am surprised that your program continues to run after an access violation. Perhaps VC 6 has something new for debugging that allows a program to continue execution in spite of an access violation; if so, I would not know about it since I still use VC 5. You might check to see if it is possible to get the debugger to stop when an access violation occurs. If you can do that then you can look at the stack and you might get a good indication of the problem. Are you sure you are working with a debug version of your program? You should, if you are getting errors like that.
-
When you get your access violation don't cancel let it go into the debugger and look thru call stack window and start putting break points in in only the cpp's that you made not the one's from MS.