PeHeaders FromUnmanagedPtr throws exception

[Critter79606]

I had an instance where modulePtr was -1 when entering FromUnmanagedPtr(), which threw an exception.
I added the following code to ReadAssemblyDebugInfo()

PeHeaders^ peHdrs = PeHeaders::FromUnmanagedPtr(modulePtr);
if( !peHdrs )
return nullptr;
....

and the following to FromUnmanagedPtr

static PeHeaders^ FromUnmanagedPtr(IntPtr memoryPtr)
{
if( (int)memoryPtr == -1 )
{
return nullptr;
}
....

This resolved the issue.

[gimelfarb]

Do you know in context of which Assembly this occurred? Was it a dynamic in-memory assembly?

[Critter79606]

All I could pull out of the debugger is that it was a Microsoft Assembly. Didn’t give me much else.
The original exception was a CommunicationException thrown by WCF due to a serializing error.

The first time calling FromUnmanagedPtr(), the memoryPtr was -1, which caused headers->Load() to actually throw the exception at dosHeader = FromMemoryPtr<IMAGE_DOS_HEADER>(memPtr, index); (values were -1,0). All of the next calls to the method had valid values.
By trapping the -1 and skipping the null value, I was able to stop the exception and continue with the report of the error below. It still gave me 100% of the info I needed to resolve my issue, and I can't see anything that would be missing.

System.ServiceModel.CommunicationException: There was an error in serializing body of message DoTransactionRequest: 'There was an error generating the XML document.'. Please see InnerException for more details. ---> System.InvalidOperationException: There was an error generating the XML document. ---> System.InvalidOperationException: Value of ItemElementName mismatches the type of wcf.ws.xxxxxxxxxxxx.xxxxxxxxxxxx; you need to set it to wcf.ws.xxxxxxxxxxxx.xxxxxxxxxxxx.@xxxxxxxxxxxx.
at Microsoft.GeneratedCode!0x06000007!Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPosGatewayInterface.Write184_PosRequestVer10Transaction(String n, String ns, PosRequestVer10Transaction o, Boolean isNullable, Boolean needType) +0x1c7c
at Microsoft.GeneratedCode!0x06000005!Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPosGatewayInterface.Write187_PosRequestVer10(String n, String ns, PosRequestVer10 o, Boolean isNullable, Boolean needType) +0x9b
at Microsoft.GeneratedCode!0x06000004!Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPosGatewayInterface.Write188_PosRequest(String n, String ns, PosRequest o, Boolean isNullable, Boolean needType) +0xaf
at Microsoft.GeneratedCode!0x06000003!Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationWriterPosGatewayInterface.Write281_Item(Object[] p) +0x17
at Microsoft.GeneratedCode!0x06000240!Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer1.Serialize(Object objectToSerialize, XmlSerializationWriter writer) +0x0
at System.Xml!0x06001e92!System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id) +0x7d
--- End of inner exception stack trace ---
at System.Xml!0x06001e92!System.Xml.Serialization.XmlSerializer.Serialize(XmlWriter xmlWriter, Object o, XmlSerializerNamespaces namespaces, String encodingStyle, String id) +0xf4
at System.ServiceModel!0x06003829!System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.SerializeBody(XmlDictionaryWriter writer, MessageVersion version, XmlSerializer serializer, MessagePartDescription returnPart, MessagePartDescriptionCollection bodyParts, Object returnValue, Object[] parameters) +0x74
at System.ServiceModel!0x06003828!System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.SerializeBody(XmlDictionaryWriter writer, MessageVersion version, String action, MessageDescription messageDescription, Object returnValue, Object[] parameters, Boolean isRequest) +0x0
--- End of inner exception stack trace ---
at mscorlib!0x06005549!System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) +0x27
at mscorlib!0x06005554!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) +0x1a4
at xxxxxxxxxxxx!0x060007c2!wcf.ws.xxxxxxxxxxxx.xxxxxxxxxxxx.xxxxxxxxxxxx(xxxxxxxxxxxx request)

at xxxxxxxxxxxx!0x060007c1!ccService.xxxxxxxxxxxx.xxxxxxxxxxxx() +0x20d

MODULE: Microsoft.GeneratedCode => Microsoft.GeneratedCode, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null;
MODULE: mscorlib => mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089; G:ea27792383b44da1a1025670606ea63d; A:2
MODULE: xxxxxxxxxxxx => xxxxxxxxxxxx, Version=1.0.5823.27284, Culture=neutral, PublicKeyToken=null; G:77d1eaba8c9f4af3b270b08496daec3c; A:10
MODULE: System.ServiceModel => System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089; G:61a1f8e8afff4cf58674808264776900; A:2
MODULE: System.Xml => System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089; G:fdba5ba73450436dbcd7f159cd7c8365; A:2

Also, in case you want to update the SymbolLoader.cs, the VS 2015 guid is "e6756135-1e65-4d17-8576-610761398c3c" // VS 2015 (msdia140.dll)

[gimelfarb]

@Critter79606 Thank you very much for the comprehensive information! I think I know what happened, and this is indeed a bug. The module 'Microsoft.GeneratedCode' (which participated in XML serialization) is a generated in-memory assembly, and it does not have HINSTANCE (just as documentation says), would return -1 to indicate that. I should be checking for it, and returning null (since this assembly does not contain debug info anyway).

And thanks for the VS 2015 GUID, I'll update it.

[Critter79606]

I'm glad I could contribute. I've only just started adding this to my code, but I see it saving me hours of time trying to replicate an issue to find out the exact line that may cause an issue.