I'm debugging a .NET 4.0 web application using a full crash dump and Windbg. I seem able to get all the versions of everything to match up however when I try to get the managed stack trace of all the thread I get
OS Thread Id: 0x7cd4 (13)
Child SP IP Call Site
GetFrameContext failed: 1
For all of my managed threads. Any ideas what I'm doing wrong and how I can fix it?
I was also getting this error, but I noticed that running !DumpStack does give me a trace when !ClrStack does not.
According to this link it could just be a thread that has been scheduled but is not running. In other words not necessarily a problem. I'm not sure why the clrstack command doesn't work though, possibly an sos bug?
0:037> !clrstack
OS Thread Id: 0x57cc (37)
Child SP IP Call Site
GetFrameContext failed: 1
0:037> !dumpstack
OS Thread Id: 0x57cc (37)
Child-SP RetAddr Call Site
000000000772f688 000007fefdb210dc ntdll!NtWaitForSingleObject+0xa
000000000772f690 000007fef5ca36ca KERNELBASE!WaitForSingleObjectEx+0x79
000000000772f730 000007fef5ca3a97 clr!CLRSemaphore::Wait+0xaa
000000000772f7f0 000007fef5ca3c20 clr!ThreadpoolMgr::UnfairSemaphore::Wait+0x140
000000000772f830 000007fef5cb21ff clr!ThreadpoolMgr::NewWorkerThreadStart+0x2a7
000000000772f8d0 000007fef5cb0582 clr!ThreadpoolMgr::WorkerThreadStart+0x3b
000000000772f970 00000000778d652d clr!Thread::intermediateThreadProc+0x7d
000000000772fb30 0000000077b0c521 kernel32!BaseThreadInitThunk+0xd
000000000772fb60 0000000000000000 ntdll!RtlUserThreadStart+0x1d
How are you trying to display the managed stack? You should be using sos or sosex (preferably sosex). Does !sosex.mk work for you?
Download sosex from here.
If you are using windbg to debug .net, you want sosex to do it.
Have you tried installing Psscor4 WinDbg extension? Here is some very useful article on how to do that.
Related
Our application is using CefSharp version 73.1.130. The issue only occurs on a small number of internal workstations within our organization. Worth noting, we are also seeing the same error with CefSharp version 92. Another strange thing is that it the issue is consistent, but only when the web apps are launched through certain navigations. Other navigations work consistently for these users.
We use RegisterJsObject to register a javascript object with browser. If I understand correctly, asynchronous binding is preferred moving forward.
The issue presents as strange/unexpected behavior in the hosted web application due to failure to retrieve context from the host WinForms application. The behavior would suggest a failure to register/bind the js object with the RegisterJsObject method. However, that method is not throwing an exception.
Enabled Cef logging showed the following error:
ERROR:JavascriptRootObjectWrapper.cpp(34)] IBrowserProcess is null, unable to bind object
After looking into the code, it appears the location that the value pointed to by "IBrowserProcess" is set is in WcfEnabledSubProcess::OnBrowserCreated (https://github.com/cefsharp/CefSharp/blob/cefsharp/73/CefSharp.BrowserSubprocess.Core/WcfEnabledSubProcess.cpp). I was able to build CefSharp and add additional logging to that method.
On my workstation (I'm not affected by the issue), I get through OnBrowserCreated with no exceptions. However, on my coworkers workstation I see the following line is failing:
...
channelFactory->Open();
auto browserProcess = channelFactory->CreateChannel();
auto clientChannel = ((IClientChannel^)browserProcess);
try
{
clientChannel->Open(); <-- FAILS
browser->ChannelFactory = channelFactory;
browser->BrowserProcess = browserProcess;
}
catch (Exception^)
{
}
}
With the error:
There was an error reading from the pipe: The pipe has been ended. (109, 0x6d)
Has anyone seen this issue before? I'm not sure how much this will help, but does anyone know if it's possible to enable WCF tracing with the CefSharp.BrowserSubProcess.exe. I have been trying this, but no luck so far.
I wanted to try out IDEA because I kinda want to move away from Eclipse. However, everytime I try to build or run code from inside IDEA, it just crashes with no error message. The only information I get is from Windows itself:
Problemsignatur (Problem signature):
Problemereignisname (Problem event name): BEX
Anwendungsname (Application name): idea.exe
Anwendungsversion (Application version): 14.0.3.0
Anwendungszeitstempel (Application timestamp): 5437b4c8
Fehlermodulname (Error module name): SDHook32.dll
Fehlermodulversion (Error module version): 2.3.39.2
Fehlermodulzeitstempel (Error module timestamp): 535a5137
Ausnahmeoffset (Exception offset): 00025942
Ausnahmecode (Exception code): c0000417
Ausnahmedaten (Exception data): 00000000
Betriebsystemversion (Operating system version): 6.1.7601.2.1.0.256.48
Gebietsschema-ID (Area schema ID): 3079
Zusatzinformation 1 (Additional information 1): 6ec5
Zusatzinformation 2 (Additional information 2): 6ec5ee19c106a54dd0feced4a6ea5c17
Zusatzinformation 3 (Additional information 3): 633b
Zusatzinformation 4 (Additional information 4): 633bad3421e95a8b92bd60a69d1ca25c
Sorry that it is in German, I tried to translate the keys into English but don't know if they actually match the English version of the error message. I'm running Windows 7 64-bit, error happens with both 32-bit and 64-bit version of IDEA. Used JDK is 1.8.0_20 (also 64-bit).
Can't seem to find anything about this on Google, maybe one of you knows how to fix this.
This is a windows issue. It's just that it is happening to you when using IntelliJ IDEA. The key in the error message is the Problem Event Name: BEX line. BEX refers to Buffer Overflow Exception. Take a read through the post Problem Event Name: BEX, error message on Microsoft Answers and the Data Execution Prevention TechNet article referenced in that answer. You can also Google windows bex crash or a similar term. Most information refers to the need to make a settings change to the "Data Execution Prevention" option. If you continue to have issues, you may want to post as a Windows-7 question on SuperUser.com
The crash happens in a DLL which is part of this application. You may want to uninstall the application if you don't need it.
The following message can be found in the server log in the file system on the Domino server:
java.lang.NullPointerException
at com.ibm.xsp.component.UIDataPanelBase.encodeEnd(UIDataPanelBase.java:280)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:856)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.util.FacesUtil.renderComponent(FacesUtil.java:851)
at com.ibm.xsp.component.UIViewRootEx._renderView(UIViewRootEx.java:1317)
at com.ibm.xsp.component.UIViewRootEx.renderView(UIViewRootEx.java:1255)
at com.ibm.xsp.application.ViewHandlerExImpl.doRender(ViewHandlerExImpl.java:641)
at com.ibm.xsp.application.ViewHandlerExImpl._renderView(ViewHandlerExImpl.java:320)
at com.ibm.xsp.application.ViewHandlerExImpl.renderView(ViewHandlerExImpl.java:335)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:103)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:210)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
at com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:219)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:583)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
Is there any way to get more info about the error? If there is, how to get more details?
First, I would suggest that you install the LogReader from OpenNTF.org by Jakob Majkilde (http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPages%20Log%20File%20Reader). It will give you easy access to the various logfiles on the server. You may need to look at different log files for specific issues - sometimes they land in the not so obvious place ;-)
When you have installed the log reader then look at messages just after (or perhaps before) the message above. In many cases several exceptions will be thrown - and you should look for the ones that refer to your own code. Changes are that you have missed initialization of an object in your own code. If you code in Java then the logs will be even more helpful.
In addition you could (should) consider using some kind of logging mechanism in your own code to tell you how far in loading/processing a page you are before failing. You could use the XPages OpenLog Logger: http://www.openntf.org/main.nsf/project.xsp?r=project/XPages%20OpenLog%20Logger
/John
I'm working with JNI and trying to unload (destroy) the VM using DestoryJavaVM function (I first call DetachCurrentThread method). It seems like the it has now influence on the VM and it is still up after the call. I read in old Sun posts that DestoryJavaVM had problems in the past (JDK1.1-1.3 in 2001) but I'm using JRE 6 and it probably should work now, right?
I need to Load\Unload a VM in the same living process since each loading requires another classes to load. Any ideas how it can be done?
Additional info:
At the unloading phase I can successfully detachCurrentThread and destroyVM (both return JNI_OK). I even FreeLibray (jvm.dll) successfuly (return 1).
When I try to Load the JVM again I can LoadLibrary(), then find the CreateVM function in the DLL and the call to CreateVM fails (return -1). What I'm doing wrong here?
Thanks,
Guy
Although it wouldn't answer your question on DestroyJavaVM.
OSGi comes to my mind you could put all classes in a bundle activate it run code and deactivate it, later you use another bundle. See Apache Felix.
Another option less elegant would be to exit the vm and restart it with another classpath.
You might check for errant threads. The Invocation API: Unloading the VM mentions, "The VM waits until the current thread is the only non-daemon user thread before it actually unloads." This is required by the Java Language Specification, 12.8.
DestroyJavaVM() doesn't support VM unloading.
DestroyJavaVM
Unloads a Java VM and reclaims its resources.
Any thread, whether attached or not, can invoke this function. If the current thread is attached, the VM waits until the current thread is the only non-daemon user-level Java thread. If the current thread is not attached, the VM attaches the current thread and then waits until the current thread is the only non-daemon user-level thread.
[...]
Unloading of the VM is not supported.
The documentation can seem a bit conflicting at first. What you can do is destroy your VM without problems, but since it doesn't unload properly you can never reload it again in the same process.
For any newbies visiting this question, refer Calling JNI_CreateJavaVM function twice
Short answer: You CANNOT create more than one JVM in a single process (this is by design).
I've created a COM object using NATIVE c++ - both COM object and it's native client works perfectly.
the next step was to implement the COM object as a out of process COM server( hosted by the dllhost process.
I followed the standard registry-change procedure(http://support.microsoft.com/kb/198891) and both client and COM server started to work properly under the dllhost.exe process.
However, I can see that sometime the host server crashes and the dllhost.exe pop up a message stating error 217 - nothing else is detailed.
Any idea how can I debug the COM infrastructure? any preferred tools I can use?
many thanks,
Ofer
However, I can see that sometime the
host server crashes and the
dllhost.exe pop up a message stating
error 217 - nothing else is detailed.
I'm curious as to what happens here, in more detail -- does the dllhost process really crash (with a structured exception) or does it show a message box and then die?
You should be able to attach any debugger (Visual Studio or WinDBG) either when the problem happens or at any time in advance.
Break into the debugger and check the callstack when the problem occurs.
If it's due to a race condition of some kind, it may not surface when the debugger is attached, so I'd start with attaching when the message box is shown, and see what information can be gathered from there.
Presumably your code is in the callstack; if not, you may be short on luck.
Note that it always helps to have Microsoft symbols available, it's easiest via the public symbol server as described at the bottom of this page:
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx