Closed Bug 5204 Opened 26 years ago Closed 26 years ago

GPF when attempting to use npmoxctl component

Categories

(Core Graveyard :: Embedding: ActiveX Wrapper, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: drose, Assigned: locka)

Details

Hi, I am currently trying to test the Mozilla control in our app (COAST WebMaster) which currently embeds IE. I have registered the control, set the PATH environment variable, and added the CWebBrowser2 class to the project. I then used the CWebBrowser2 class instead of the CWebBrowser (IE) class for instantiating the Browser object. When I run our app in the debugger, it GPFs pretty much immediately. I am using the M4 release (build ID 1999941412) on NT Service Pack 4 in Visual Studio 6 (SP2). The call stack at the point of the GPF is: NTDLL! RtlpWaitForCriticalSection@4 + 149 bytes NTDLL! RtlEnterCriticalSection@4 + 70 bytes NPMOZCTL! 1000a0ba() NPMOZCTL! 10009e6b() RAPTORWEB! 01ea3ba5() NETLIB! 01f629ac() USER32! CallWindowProcA@20 + 25 bytes _AfxActivationWndProc(HWND__ * 0x0001021e, unsigned int 49454, unsigned int 0, long 14716736) line 428 + 26 bytes USER32! DispatchMessageWorker@8 + 135 bytes USER32! DispatchMessageA@4 + 11 bytes CWinThread::PumpMessage() line 846 CWnd::RunModalLoop(unsigned long 4) line 3478 + 19 bytes CDialog::DoModal() line 539 + 12 bytes CMainFrame::OnFileSetHomePage(CString {""}, int 1) line 1122 + 11 bytes CWebTreeView::OnInitialUpdate() line 492 CWnd::OnWndMsg(unsigned int 868, unsigned int 0, long 0, long * 0x0012fbbc) line 1825 CWnd::WindowProc(unsigned int 868, unsigned int 0, long 0) line 1585 + 30 bytes AfxCallWndProc(CWnd * 0x01746740 {CWebTreeView hWnd=0x000c0220}, HWND__ * 0x000c0220, unsigned int 868, unsigned int 0, long 0) line 215 + 26 bytes CWnd::SendMessageToDescendants(HWND__ * 0x00010206, unsigned int 868, unsigned int 0, long 0, int 1, int 1) line 2309 CWnd::SendMessageToDescendants(HWND__ * 0x00010202, unsigned int 868, unsigned int 0, long 0, int 1, int 1) line 2320 CWnd::SendMessageToDescendants(unsigned int 868, unsigned int 0, long 0, int 1, int 1) line 146 + 32 bytes CFrameWnd::InitialUpdateFrame(CDocument * 0x01733778 {CWebMasterDoc}, int 1) line 753 CDocTemplate::InitialUpdateFrame(CFrameWnd * 0x01733f50 {CMainFrame hWnd=0x00010202}, CDocument * 0x01733778 {CWebMasterDoc}, int 1) line 332 CSingleDocTemplate::OpenDocumentFile(const char * 0x00000000, int 1) line 205 CDocManager::OnFileNew() line 829 CWinApp::OnFileNew() line 29 CWebMasterApp::InitInstance() line 200 AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00143496, int 1) line 39 + 11 bytes WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00143496, int 1) line 30 WinMainCRTStartup() line 198 + 54 bytes KERNEL32! BaseProcessStart@4 + 64 bytes I hope this helps. If you need any more info, feel free to ask. Dave Rose
Could you retry this with M5 and VB6?
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → INVALID
The stack trace looks like there is a problem in the host application, not the control. If I am incorrect about this, could you retry your app with M5 and see if you can replicate the problem?
Status: RESOLVED → VERIFIED
Sorry I haven't followed up on this, but I'm on vacation for the summer. I won't be able to do any testing on this from my end until I get back, in September. Here's any extra information I can remember about the bug. I hope it's helpful in some way. When I was testing, I tried manipulating our app, to get around the GPF. One constant was that no matter which methods in our app were triggered, the GPF always occurred after a CDialog::DoModal call. Which path in our app triggered that didn't seem to matter. One other piece of information. In the call stack I provided, the last call based on our code (not MFC code) is CMainFrame::SetHomePage. This method does not use the browser object in any way, but does instantiate a modal dialog. I'm not sure why, but as mentioned before, it seems that the CDialog::DoModal call is triggering the GPF. It may have to do with threading issues in the MFC, but that's only a guess. Also, as mentioned before, the only change made from using IE as the embedded browser, to using Mozilla was creating a CMozillaWebBrowser class and making our browser object of that type rather than the CWebBrowser class based on the IE control. Our app works without any problem with the IE control. This is pretty much all I can remember of the problem. Dave Rose
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.