Link to home
Start Free TrialLog in
Avatar of GeekHipster
GeekHipster

asked on

.NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (7A097706) (80131506)

I am using .NET 3.5 SP1, VS2008 and the following code to resolve UNC paths, which is working fine on Vista machines, but is crashing on some Windows XP machines.  Please assume for the purposes of my question that GetUName in my code sample is returning 0, which frustratingly, it is.

GetUName is returning 0 for success, and the error is happening on the line "Marshal.PtrToStructure(lpBuffer, uname)"

The CLR does not trap the exception and I get a generic Windows error message asking me to send an error report just before the application shuts down.

On a Terminal Server with Windows Server 2003 Enterprise Edition Service Pack 2 the following information about two errors can be found in the Application Event log when this happens

Event Type:      Error
Event Source:      .NET Runtime
Event Category:      None
Event ID:      1023
Date:            7/21/2009
Time:            3:51:41 PM
User:            N/A
Computer:      MYTS
Description:
.NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (7A097706) (80131506)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:      Error
Event Source:      .NET Runtime 2.0 Error Reporting
Event Category:      None
Event ID:      1000
Date:            7/21/2009
Time:            3:51:47 PM
User:            N/A
Computer:      MYTS
Description:
Faulting application some random program.exe, version 1.0.0.0, stamp 4a661bd2, faulting module mscorwks.dll, version 2.0.50727.3053, stamp 4889dc18, debug? 0, fault address 0x000f6b04.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00   A.p.p.l.
0008: 69 00 63 00 61 00 74 00   i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00   i.o.n. .
0018: 46 00 61 00 69 00 6c 00   F.a.i.l.
... etc...


Similarly on a Windows XP Professional Version 2002 Service Pack 3, the following error information is available:

Event Type:        Error
Event Source:    .NET Runtime 2.0 Error Reporting
Event Category:                None
Event ID:              1000
Date:                     7/21/2009
Time:                     1:41:12 PM
User:                     N/A
Computer:          DEVPC3
Description:
Faulting application some britec app.exe, version 1.0.0.0, stamp 4a65f9e3, faulting module mscorwks.dll, version 2.0.50727.3082, stamp 492b82c1, debug? 0, fault address 0x000f6b94.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00   A.p.p.l.
0008: 69 00 63 00 61 00 74 00   i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00   i.o.n. .
0018: 46 00 61 00 69 00 6c 00   F.a.i.l.
0020: 75 00 72 00 65 00 20 00   u.r.e. .
... etc....

Event Type:        Error
Event Source:    .NET Runtime
Event Category:                None
Event ID:              1023
Date:                     7/21/2009
Time:                     1:41:10 PM
User:                     N/A
Computer:          DEVPC3
Description:
.NET Runtime version 2.0.50727.3082 - Fatal Execution Engine Error (7A0979C6) (80131506)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



In an effort to replicate this error, I have built a Virtual PC running Windows XP Professional Version 2002 Service Pack 3, but the error does not happen, I get my UNC path as expected.

A few internet searches found several folks with this same error, but no reliable fixes or answers, and nothing specific to my situation.

A managed .NET way of resolving UNC paths may be a nice way to just avoid the whole mess.  :)

Any ideas experts?











Public Class myClass
 
<DllImport("mpr.dll", Entrypoint:="WNetGetUniversalName", CharSet:=CharSet.Auto, SetLastError:=False)> _
Private Shared Function GetUName(ByVal Path As String, ByVal outName As INFO_LEVEL, _
ByVal bObj As IntPtr, ByRef bSize As Integer) As Integer
End Function
 
Public Shared Function GetUnivseralName(ByVal myPath As String) As String
 
        Dim uname As New UNIVERSAL_NAME_INFO
        Dim bufSize As Integer = 1000
        Dim lpBuffer As IntPtr = Marshal.AllocHGlobal(bufSize)
 
        Dim result As String = myPath
        Dim ret As Int32 = GetUName(result, INFO_LEVEL.UNIVERSAL_NAME_INFO_LEVEL, lpBuffer, bufSize)
 
        Marshal.PtrToStructure(lpBuffer, uname)
 
        Marshal.FreeHGlobal(lpBuffer)
 
        Return uname.UniversalName.ToString()
 
End Function
 
End Class
 
<StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Auto), Serializable()> _
    Class UNIVERSAL_NAME_INFO
        <MarshalAs(UnmanagedType.LPTStr)> Public UniversalName As String
        <MarshalAs(UnmanagedType.LPTStr)> Public ConnectionName As String
        <MarshalAs(UnmanagedType.LPTStr)> Public RemainingPath As String
    End Class

Open in new window

ASKER CERTIFIED SOLUTION
Avatar of abel
abel
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of GeekHipster
GeekHipster

ASKER

1, 2.  Yes thanks, I've just trimmed out some code for clarity.  I only WISH it were actually throwing an Exception, then I probably wouldn't be here, but it just ends the program.

3, 4.  Yes it appears to have been something to do with the way I was marshalling / casting things.

I found this article which handles the WNet function calls sligthly different than me, and they work for me on all versions of mpr.dll that I have tried.
http://www.codeproject.com/KB/dotnet/DotNetWrapperForWNet.aspx

For anyone else that runs into this problem, the version of mpr.dll that was causing my code trouble was 5.2.3790.3959  A few other versions I tried on different OSs, all newer, all worked fine.
Good resource. That actually does what I suggested and what is written in the pinvoke.net (and a lot more for the other functions as well). It adds the marshalling information to the UNIVERSAL_NAME_INFO, called RemoteNameInfo in your link, again the same way as on the pinvoke.net.

What I'm trying to say: it's good that you found it yourself, but on EE, when two people find likewise solutions to a problem, it is common to merit that. May I suggest you accept your comment as answer and assign the points to mine as assisting answer?
Objection because I am under the impression that both the answer of the asker and the answer of mine (which was quite a while before that) contain the answer. I am OK with the asker's comment as an answer, but would like to see my comment as assisting solution.

This would be in accordance to the way I understand the comment of the asker, where (s)he seconds that my points lead indeed to the same solution and the links in both comments point to similar solutions.