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)
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
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?
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
Updated•13 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•