In converting existing applications to VS2005 we have encountered this problem. I created a small test application to reproduce what we see in our ASP.NET code. The C# test application first creates an Object using 'Activator.GetObject' specifying a well known port and URI for the C# Object. The C# code then attempts to call a method on that object and the application hangs. When I break into the debugger (mixed mode) the call stack shows:
[Managed to Native Transition]
System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer = {Dimensions:[4096]}, int offset = 0, int size, System.Net.Sockets.SocketFlags socketFlags = None, out System.Net.Sockets.SocketError errorCode = Success) + 0x136 bytes
System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags) + 0x1d bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.SocketStream.Read(byte[] buffer, int offset, int size) + 0x30 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.ReadFromSocket(byte[] buffer, int offset, int count) + 0x16 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.BufferMoreData() + 0x12 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.Read(byte[] buffer = {Dimensions:[4]}, int offset = 0, int count = 4) + 0x64 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.ReadAndMatchFourBytes(byte[] buffer = {Dimensions:[4]}) + 0x14 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadVersionAndOperation(out ushort operation = 0) + 0x31 bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.ReadHeaders() + 0x2a bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(System.Runtime.Remoting.Messaging.IMessage msg, System.Runtime.Remoting.Channels.ITransportHeaders requestHeaders, System.IO.Stream requestStream, out System.Runtime.Remoting.Channels.ITransportHeaders responseHeaders = null, out System.IO.Stream responseStream = null) + 0x1a bytes
System.Runtime.Remoting.dll!System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage msg) + 0x59 bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.CallProcessMessage(System.Runtime.Remoting.Messaging.IMessageSink ms, System.Runtime.Remoting.Messaging.IMessage reqMsg, System.Runtime.Remoting.Contexts.ArrayWithSize proxySinks = null, System.Threading.Thread currentThread, System.Runtime.Remoting.Contexts.Context currentContext = {System.Runtime.Remoting.Contexts.Context}, bool bSkippingContextChain = true) + 0x5a bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.InternalInvoke(System.Runtime.Remoting.Messaging.IMethodCallMessage reqMcmMsg, bool useDispatchMessage, int callType) + 0x2ce bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage reqMsg) + 0x125 bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(ref System.Runtime.Remoting.Proxies.MessageData msgData, int type) + 0x273 bytes
[Native to Managed Transition]
[Managed to Native Transition]
> WindowsApplication2.exe!WindowsApplication2.Form1.button1_Click(object sender = {Text = Cannot evaluate expression because a native frame is on top of the call stack.}, System.EventArgs e = {X = 153 Y = 47 Button = Left}) Line 24 + 0x9 bytes C#
System.Windows.Forms.dll!System.Windows.Forms.Control.OnClick(System.EventArgs e) + 0x57 bytes
System.Windows.Forms.dll!System.Windows.Forms.Button.OnClick(System.EventArgs e) + 0x49 bytes
System.Windows.Forms.dll!System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs mevent = {X = 153 Y = 47 Button = Left}) + 0xc3 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WmMouseUp(ref System.Windows.Forms.Message m, System.Windows.Forms.MouseButtons button, int clicks) + 0xf2 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x544 bytes
System.Windows.Forms.dll!System.Windows.Forms.ButtonBase.WndProc(ref System.Windows.Forms.Message m) + 0xce bytes
System.Windows.Forms.dll!System.Windows.Forms.Button.WndProc(ref System.Windows.Forms.Message m) + 0x2b bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 514, System.IntPtr wparam, System.IntPtr lparam) + 0x75 bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason = -1, int pvLoopData = 0) + 0x2ea bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x17d bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x53 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x2e bytes
WindowsApplication2.exe!WindowsApplication2.Program.Main() Line 17 + 0x1a bytes C#
[Native to Managed Transition]
[Managed to Native Transition]
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) + 0x32 bytes
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() + 0x2b bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x3b bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x81 bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x40 bytes
A quick watch on the object shows an remoting proxy object which contains members which have "Cannot evaluate expression because a native frame is on top of the call stack" associated with them.
The only way to get out is to kill the application.
Any help on this will be greatly appreciated.
-Richard
Application Hangs,data in remoting proxies show "Cannot evaluate expression because a native frame is on top of the call stack"
dbaeck
FYI, Eventually I had found that the COM object had not been registered properly. Previously it had been registered using .NET 1.0 and regasm.
With the new assembly I needed to register the assembly using .NET 2.0 and 'regasm /codebase'. This fixed the problem.
Thanks for all in their input.
Chris Honcoop
Richard,
The error "Cannot evaluate expression because a native frame is on top of the callstack" is expected in this case. In order to do evaluations, the runtime requires that debuggee must be stopped at a GC safe point. This means if you are stopped in unmanaged code as in this case the evaluations will not work.
In any case this is not the reason for your application hang. Have you tried running the application without debugging to see if hang repros If it does, then you can attach in mixed mode and look at all the threads. If it doesn't happen outside of debugger then launch with mixed mode debugging enabled and look at all the threads.
Azeem Khan
VS Debugger.
robinjam
Hey Everyone & Azeem,
I have experienced the same the error.
I was building an information system using C# 2005 and SQL Server 2005 for the database, using an application framework called CSLA.NET (Mad Props to Rocky!)
I loaded up my program on another computer separate from my database server, and after trying to update some records the debugger gave the error message "Cannot evaluate expression because a native frame is on top of the callstack". There was no opportunity to find an inner exception as basically the debugger was telling me the problem had occurred outside of my application.
I was more than a little confused to start with since all the components and all my code as far as I knew were managed, so where was the "native frame" coming from
Even more confusing at the time was I could fetch records but the application would hang if I tried creating a new record or updating an existing record.
It turns out (anti-climatically) that McAfee's latest (entire program) update had enabled windows firewall, as well as it's own (which contained an allow rule for msdtc), and msdtc (MicroSoft Distributed Transaction Coordinator) was not on the exception list for windows firewall.
After adding the rule to windows firewall for msdtc my program worked fine. It seems the native error comes from underlying data layers that are prevented from successfully executing, and for lack of an informative error message, displays "Cannot evaluate expression because a native frame is on top of the callstack".
So I've seen a lot of chatter on a bunch of forums about this error, and nobody seems to be able to give a definitive reason for it's appearance or a solution that works for everyone.
So here's my answer this error: Check that your application has access to all the levels of data processing necessary.
This may mean inspecting your firewall settings, or starting services which are stopped or disabled by default, or configuring database drivers or servers, or user priviliges. Basically there is a lot of indirection in the data layers so follow the white rabbit and check all your settings.
I hope this insight offers hope to those who feel like sanity and logic has left the room when they get this error message!
Voss.