none
Unhandled exception in jscript9.dll in Windows Server 2016 when using MFC's CDHtmlDialog, after installing Microsoft update KB4507460 RRS feed

  • Question

  • Hi.

    An unhandled exception occurs in jscript9.dll in Windows Server 2016 when using MFC's CDHtmlDialog, after installing Microsoft update KB4507460.

    I've attached a reproducible example here.


    Windows Server 2016 (64-bit) Version 1607 (OS Build 14393.3085)

    Visual Studio 2017 15.9.14

    jscript9.dll mshtml.dll v11.0.14393.3085

    Steps to reproduce:

    1. Download and unzip HtmlBrowser.zip.

    2. Open HtmlBrowser.sln in Visual Studio 2017.

    3. Select the "Debug | x64" solution configuration.

    4. Start debugging the HtmlBrowser project.

    Notice a similar exception as follows:

    Exception thrown at 0x00007FFCFB1D4C48 in HtmlBrowser.exe: Microsoft C++ exception: Js::JavascriptExceptionObject at memory location 0x0000008C78FB9EE0.

    Call Stack:

         [External Code]    
         jscript9.dll!Js::JavascriptExceptionOperators::ThrowExceptionObjectInternal()    Unknown
         jscript9.dll!Js::JavascriptExceptionOperators::ThrowExceptionObject(class Js::JavascriptExceptionObject *,class Js::ScriptContext *,bool,void *)    Unknown
         jscript9.dll!Js::JavascriptExceptionOperators::Throw()    Unknown
         jscript9.dll!CJavascriptOperations::ThrowException()    Unknown
         mshtml.dll!CFastDOM::ThrowDOMError()    Unknown
         mshtml.dll!CFastDOM::CElement::Trampoline_querySelectorAll(void *,struct CallInfo,...)    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::JavascriptExternalFunction::ExternalFunctionThunk()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10e73()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallFunction<1>()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_CallCommon<struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI_OneByte> >(struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI_OneByte> const *,class Js::RecyclableObject *,unsigned int)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_TryCatch()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_TryFinally()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10eb3()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10ec3()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallFunction<1>()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_CallCommon<struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI_OneByte> >(struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI_OneByte> const *,class Js::RecyclableObject *,unsigned int)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10efb()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallFunction<1>()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_CallCommon<struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI> >(struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI> const *,class Js::RecyclableObject *,unsigned int)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::OP_ProfiledReturnTypeCallI<struct Js::OpLayoutCallI>(struct Js::OpLayoutDynamicProfile<struct Js::OpLayoutCallI> const *,unsigned int)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10fbb()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::InterpreterStackFrame::Process(void)    Unknown
         jscript9.dll!Js::InterpreterStackFrame::InterpreterThunk<1>(class Js::JavascriptCallStackLayout *)    Unknown
         000001b9a8d10fc3()    Unknown
         jscript9.dll!amd64_CallFunction()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallFunction<1>()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallRootFunctionInternal()    Unknown
         jscript9.dll!Js::JavascriptFunction::CallRootFunction()    Unknown
         jscript9.dll!ScriptSite::CallRootFunction()    Unknown
         jscript9.dll!ScriptSite::Execute()    Unknown
         jscript9.dll!ScriptEngine::ExecutePendingScripts()    Unknown
         jscript9.dll!ScriptEngine::ParseScriptTextCore()    Unknown
         jscript9.dll!ScriptEngine::ParseScriptText()    Unknown
         mshtml.dll!CActiveScriptHolder::ParseScriptText()    Unknown
         mshtml.dll!CJScript9Holder::ParseScriptText()    Unknown
         mshtml.dll!CScriptCollection::ParseScriptText()    Unknown
         mshtml.dll!CScriptData::CommitCode()    Unknown
         mshtml.dll!CScriptData::Execute()    Unknown
         mshtml.dll!CHtmScriptParseCtx::Execute()    Unknown
         mshtml.dll!CHtmParseBase::Execute()    Unknown
         mshtml.dll!CHtmPost::Broadcast()    Unknown
         mshtml.dll!CHtmPost::Exec()    Unknown
         mshtml.dll!CHtmPost::Run()    Unknown
         mshtml.dll!PostManExecute()    Unknown
         mshtml.dll!CPostManager::PostManOnTimer()    Unknown
         mshtml.dll!GlobalWndOnMethodCall(void)    Unknown
         mshtml.dll!GlobalWndProc()    Unknown
         user32.dll!UserCallWinProcCheckWow()    Unknown
         user32.dll!CallWindowProcW()    Unknown
    >    mfc140ud.dll!_AfxActivationWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 478    C++
         user32.dll!UserCallWinProcCheckWow()    Unknown
         user32.dll!DispatchMessageWorker()    Unknown
         mfc140ud.dll!AfxInternalPumpMessage() Line 183    C++
         mfc140ud.dll!CWinThread::PumpMessage() Line 900    C++
         mfc140ud.dll!AfxPumpMessage() Line 190    C++
         mfc140ud.dll!CWnd::RunModalLoop(unsigned long dwFlags) Line 4661    C++
         mfc140ud.dll!CWnd::CreateRunDlgIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 470    C++
         mfc140ud.dll!CDialog::DoModal() Line 633    C++
         HtmlBrowser.exe!CHtmlBrowserApp::InitInstance() Line 73    C++
         [External Code]    
         HtmlBrowser.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 26    C++
         [External Code]    

    I'm also wondering how I can prevent the JavaScript error from crashing the desktop application?

    Thank you.


    Sunday, July 14, 2019 3:08 AM

Answers

All replies

  • Hi,

    Thank you for posting here.

    >>Exception thrown at 0x00007FFCFB1D4C48 in HtmlBrowser.exe: Microsoft C++ exception: Js::JavascriptExceptionObject at memory location 0x0000008C78FB9EE0.

    I suggest you could try to disable the JavaScript error in Webbrowser control.

    >>I'm also wondering how I can prevent the JavaScript error from crashing the desktop application?

    I suggest you try to capture the OLECMDID.OLECMDID_SHOWSCRIPTERROR message by implementing the IOleCommandTarget.Exec method and then avoid the exception.

    Best Regards,

    Jeanine Zhang

    Monday, July 15, 2019 3:31 AM
    Moderator
  • Hi Jeanine Zhang.

    Thank you for your reply and suggested resolution.

    The resolution only works when I run the application in the Debug configuration.

    If I run the application in the Release configuration (without Debugging), it still crashes.

    I've updated the code to set

    m_pBrowserApp->put_Silent(VARIANT_TRUE);

    to disable reporting Javascript errors and also implemented IOleCommandTarget.Exec.

    HtmlBrowser.zip

    Any ideas?

    Thank you.


    Tuesday, July 16, 2019 5:38 AM
  • Hi,

    >>The resolution only works when I run the application in the Debug configuration. If I run the application in the Release configuration (without Debugging), it still crashes.

    Debug builds set uninitialized locals to a special value to facilitate debug tracking. When a Release build is run these variables will have random contents, depending on what's in that memory location at the time the program is run.

    I suggest you could try to build with the highest Warning Level (/W4) set ,It should have issued warnings about using uninitialized variables and pointed to the offending line(s). And then be sure to resolve all warnings from the build.

    Best Regards,

    Jeanine Zhang

    Tuesday, July 16, 2019 7:53 AM
    Moderator
  • Hi.

    I set the highest warning level (/W4), rebuilt the project, but the only warnings displayed are "unreferenced formal parameter".

    Any other ideas?

    Thank you.

    Tuesday, July 16, 2019 8:05 AM
  • I set the highest warning level (/W4), rebuilt the project, but the only warnings displayed are "unreferenced formal parameter".

    Any other ideas?

    Hello,

    the compiler cannot recognize everthing.

    You say, the programme doesn't "crash" in Debug mode but only in Release, so it must be some kind of uninitialized variable used, or the size of an array is wrong used, or a pointer to memory is deallocated and used after, etc.

    Use for example WinDbg to analyze the dump file. http://www.windbg.org/

    You can also use a minidump like in https://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu

    Regards, Guido



    Tuesday, July 16, 2019 9:17 AM
  • Hi Guido Franzke.

    I used WinDbg to analyze the dump file but the stack doesn't include the source file, function, or line numbers in any of my code as expected.

    OLECMDID_SHOWSCRIPTERROR is never actually sent.

    The issue only occurs with the particular website being navigated to for some reason.

    For example, navigating to http://support.zendesk.com will cause the crash.

    But navigating to that web site in IE11 doesn't crash IE.

    How do I catch the DOM error/exception?

    Thank you.

    Tuesday, July 16, 2019 9:29 PM
  • I discovered that if I set the following registry value, then the application doesn't crash:

    Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main
    Value: Disable Script Debugger
    Type: REG_SZ
    Data: no

    Tuesday, July 16, 2019 10:07 PM
  • Since this setting affects other applications, I'm wondering if I can control this behavior specifically for my CDHtmlDialog / web browser control?

    Thank you.

    Tuesday, July 16, 2019 10:19 PM
  • Hi,

    >>Since this setting affects other applications, I'm wondering if I can control this behavior specifically for my CDHtmlDialog / web browser control?

    I suggest you could refer to the link:
    https://social.msdn.microsoft.com/Forums/vstudio/en-US/6f1463c6-59a0-48eb-9fdc-22383cc8b255/how-to-disable-webbrowser-script-error?forum=vcgeneral
    https://stackoverflow.com/questions/2476360/disable-javascript-error-in-webbrowser-control

    Best Regards,

    Jeanine Zhang

    Wednesday, July 17, 2019 7:43 AM
    Moderator
  • Hi Jeanine,


    The first link has suggestions to try several things:

    1. Call CHtmlView::SetSilent(TRUE)

    This doesn't apply here because I'm not using the MFC document/view architecture.

    2. Handle the OLECMDID_SHOWSCRIPTERROR command

    This was already suggested before.

    The OLECMDID_SHOWSCRIPTERROR command is never sent before the application crashes.

    3. Handle the OLECMDID_SHOWMESSAGE command

    The OLECMDID_SHOWMESSAGE command is never sent before the application crashes.

    4. Call m_pWebBrowser->put_Silent( VARIANT_TRUE );

    This was already suggested before.

    Even though the code is called, the application still crashes.

    5. Use a custom control container management class (COccManager).

    I've added that code, but the application still crashes.


    The second link has suggestions to try a few things:

    1. Call webBrowser.ScriptErrorsSuppressed = true;

    "For the record, under the hood this property does this.AxIWebBrowser2.Silent = true"

    The code already calls m_pWebBrowser->put_Silent( VARIANT_TRUE );, but the application still crashes.

    2. Mark the error as handled in the DocumentCompleted event.

    I have added that code, but the application still crashes.

    I just don't understand why the behavior changed, specifically after installing KB4507460.

    Thursday, July 18, 2019 12:18 AM
  • Here's another user having the same issue, also related to KB4507460:

    https://forums.adobe.com/thread/2638565


    Thursday, July 18, 2019 4:57 AM
  • Hi,

    Could you please tell me which version of IE you are using? I suggest you could try to use the latest IE.

    According to the link you provided, that person disables the script debugger by setting the registry value.

    Best Regards,

    Jeanine Zhang

    Monday, July 22, 2019 7:15 AM
    Moderator
  • Hi Jeanine,

    The latest version of IE is installed on that system.

    11.3085.14393.0

    The work-around in the link I provided was written by me and I also previously mentioned the work-around in this thread.

    It's just a work-around and doesn't resolve the underlying issue.

    The application worked as expected before installing KB4507460.

    That registry value didn't need to change before KB4507460 was installed.

    Installing KB4507460 and then running the application causes jscript9.dll to throw an exception and crash the application.

    I have updated the application to try and catch the exception, but it doesn't seem like the exception gives the application a chance to handle it.

    I've provided the source code that can reproduce the issue.

    The documentation for KB4507460 doesn't indicate that changes should be made to existing applications, or that it changes existing behavior.

    But yet, it has the side effect of crashing the application.

    Setting the registry value "Disable Script Debugger" to "no" to prevent the application from crashing doesn't really make sense. Why does enabling the script debugger prevent the application from crashing?

    I found a support article from IBM which also indicates installing KB4507460 causes one of their applications to crash and the work-around is to uninstall KB4507460:

    https://www.ibm.com/support/docview.wss?uid=ibm10959251

    Monday, July 22, 2019 5:27 PM
  • Hi,

    As far as I'm concerned, the issue caused by KB4507460. This KB4507460 appears to have changed the way IFRAME contents are loaded. I suggest you should try to uninstall the update and pause Windows Updates.

    I suggest you could post this issue on the Developer Community for better help.

    Best Regards,

    Jeanine Zhang

    Tuesday, July 23, 2019 2:20 AM
    Moderator
  • Tuesday, July 23, 2019 4:29 AM
  • The KB4512517 update, released today, has resolved the issue.
    • Proposed as answer by Guido Franzke Wednesday, August 14, 2019 6:11 AM
    • Marked as answer by RamiAbuGhazaleh Wednesday, August 14, 2019 9:09 AM
    Tuesday, August 13, 2019 8:40 PM