Posted: Sep 19, 2011 @ 05:54 PM             Msg. 1 of 16

We're seeing a crash that appears to originate inside the OECClient constructor. See this screenshot: http://i51.tinypic.com/2d7t3k9.png
(Apologies for the poor quality; it's what the customer gave us.)

Given that the constructor takes no arguments, I'm not sure how it could be caused by some action of our application.

The machine that triggered this is 64-bit. Has this library been well-tested on 64-bit machines?

Thanks for any help you can provide.

-Grant
Edited by THarnett81 on Sep 19, 2011 at 17:56:13
Edited by THarnett81 on Sep 19, 2011 at 17:56:48

Posted: Sep 19, 2011 @ 08:24 PM             Msg. 2 of 16

According this call stack the issue is inside .NET platform. We will research what combination of factors could lead to it.

OEC Trader on 64-bit machine is running in 64-bit mode.

---

Victor Vins
Lead Software Developer

Posted: Sep 20, 2011 @ 10:46 AM             Msg. 3 of 16

Hello,

is OECAPI constructor calling from partially trusted code?

---

Victor Vins
Lead Software Developer

Posted: Sep 20, 2011 @ 01:41 PM             Msg. 4 of 16

Not entirely sure what you mean by "partially trusted".

It's code that I wrote, and is fully part of the application.

The machine is 64-bit, but our application is running in 32-bit mode. We haven't done a full 64-bit mode build yet.

Posted: Sep 22, 2011 @ 03:39 PM             Msg. 5 of 16

Any luck?

Posted: Sep 22, 2011 @ 04:29 PM             Msg. 6 of 16

Nope. Is it possible to share with me the list of modules that are loaded in your application? Looks like some of them is not recognized correctly by .NET

---

Victor Vins
Lead Software Developer

Posted: Sep 22, 2011 @ 05:31 PM             Msg. 7 of 16

From the References folder in this project:

OpenECry/API.dll
OpenECry/CommLib.dll
OpenECry/ProtoSharp.Core.dll
System
System.configuration
System.Core
System.Windows.Forms
System.Xml.Linq
System.Data.DataSetExtensions
System.Data
System.Xml
WindowsBase

Plus 2 other libraries that are stuff we wrote; they don't much interact with the Windows innards.

Posted: Sep 26, 2011 @ 02:16 PM             Msg. 8 of 16

Could you please try to execute System.Diagnostics.Process.GetCurrentProcess().Modules.Length? It looks like .NET platform is malfunctioning on this machine.

---

Victor Vins
Lead Software Developer

Posted: Sep 26, 2011 @ 06:26 PM             Msg. 9 of 16

Unfortunately, it is a customer's machine and not mine.

Would it be adequate to write a small program that runs this command, and ask the user to run it?

Or is it required that I add this call to my application to properly test this hypothesis? It could be done, though it is not appealing.

Posted: Sep 27, 2011 @ 08:11 AM             Msg. 10 of 16

OECAPI is relying on success call of Process.Modules. If .NET platform on this machine is failing on this call, OECAPI constructor will not suppress it.

---

Victor Vins
Lead Software Developer

Posted: Sep 27, 2011 @ 09:54 AM             Msg. 11 of 16

[deleted by poster]
Edited by THarnett81 on Sep 27, 2011 at 09:59:28

Posted: Sep 27, 2011 @ 09:59 AM             Msg. 12 of 16

That didn't exactly answer my question.

If I wrote a simple app that called that function, would that be sufficient to test the user's installation?

Or would I need to alter my application?

Posted: Sep 27, 2011 @ 10:42 AM             Msg. 13 of 16

It could be something wrong with one of your modules in the application.

---

Victor Vins
Lead Software Developer

Posted: Sep 27, 2011 @ 12:23 PM             Msg. 14 of 16

Victor, in my last two posts of this thread, I've asked basically the same two yes-or-no questions. Each of your replies has studiously avoided giving me any answer to those questions.

Posted: Sep 27, 2011 @ 12:41 PM             Msg. 15 of 16

I think this should be your decision how to check it.

---

Victor Vins
Lead Software Developer

Posted: Sep 27, 2011 @ 02:28 PM             Msg. 16 of 16

I put it that call (I assume you meant "Count" rather than "Length") in my app, and it executed without problem.

However, I tried it on my dev machine, and not on the customer's machine. The customer has not responded since the initial report; until (unless) he gets back in touch, we cannot further attempt to reproduce this crash. It's likely that this crash has caused the customer to abort evaluation of our product, unfortunately.