1

I'm getting a very strange crash when testing an existing application in Windows 8. The main application is written in Delphi XE (Win32) and it does some calls to .Net assemblies using COM interop. The current .Net version being used is 3.5.

When the application executes on a fresh install of Windows 8, it crashes up to 10 times before it suddenly starts to run properly. Once it has started to do OK it will continue to do so. No error logs or error messages are shown. The application just hangs or stops working.

I have had the same result on 4 different Win8 installations, both physical and virtual.

I have been able to do some remote debugging and managed to track down the error to the .Net method Double.TryParse, when trying to parse a non-numeric value.

Double.Parse within a Try/Catch block does not work either.

The main assemblies are written in Delphi Prism, but I have been able to reproduce the error with test assemblies written in C# using VS2010.

.Net 4 seems to work properly, but due to the missing support for Oracle we're not able to upgrade right now.

The program works OK on previous versions of Windows, and also on Windows Server 2012.

Any hints or suggestions would be really appreciated.

Addition: I forgot to mention the test assembly works properly when being called from another test application written in C# / managed code. It's only the combination of Delphi (Win32), .Net 3.5, COM InterOp and Windows 8 that produces the crash.

I'm also very baffled why the application suddenly starts to work, after crashing up to 10 times.

Ken White
  • 123,280
  • 14
  • 225
  • 444
Cactus99
  • 11
  • 3
  • 1
    Is it related to Culture settings on Win8 machine? try something like double.TryParse("24.45", NumberStyles.Any, CultureInfo.GetCultureInfo("en-US"), out output); – Amitd Oct 03 '12 at 12:58
  • Nope. I have tried that as well but the application still crashes. – Cactus99 Oct 03 '12 at 13:23
  • What if you add the C# dll as a com reference to another C# project (try and take delphi out of the mix)? – John Koerner Oct 03 '12 at 13:43
  • As I added to the main post above, calling a C# assembly from another C# Project works properly. Unfortunately our main application is written in Delphi... – Cactus99 Oct 03 '12 at 13:50
  • Are you adding the reference as a native reference or a COM reference? – John Koerner Oct 03 '12 at 14:49

3 Answers3

1

Without having your code it would be very hard to troubleshoot, but I can make some recommendations.

Have you actually installed the .Net 3.5 runtime? There are some differences between running the real .Net 3.5 runtime and "emulating" it under .NET 4.0 (which comes pre-installed with Windows 8).

Next, you could try forcing the application to run under a specific runtime version by creating / modifying the assembly manifest.

Force an application to run under specific .NET runtime version?

Finally, you could try forcing your application into 32-bit space to see if there's an issue with 64-bit. Unfortunately this is controlled by the process and cannot be changed by the DLL. .NET executables can specify this in project properties or through a compiler flag:

http://msdn.microsoft.com/en-us/library/zekwfyz4(VS.80).aspx

Since this is only happening when the .NET code is running under the Delphi .NET host, I'd look to see if you have any control in Delphi over the .NET AppDomain that get's created. I'm not a Delphi developer so I can't help you here, but it looks like there's a library called JCL that may give you more control over how your code is loaded into the AppDomain.

Hosting the .NET runtime in a Delphi Program

If you are able to track this down, I recommend you share your findings with Microsoft support so they can potentially address it (assuming it's in their control to resolve).

Community
  • 1
  • 1
Jared Bienz - MSFT
  • 3,550
  • 17
  • 21
  • I've checked the Windows 8 machine and it seems .Net 3.5 is properly installed. Both the appropriate Microsoft.Net folders and registry keys exist on the machine. Since we're running out on time with this issue (with a new release of our products coming up). we'll probably try to upgrade the assemblies to .Net 4. It means differentiating our products, since we have other web applications also using the assemblies. We're not in a position to update these as well at this moment, so we're not too happy to do that. – Cactus99 Oct 04 '12 at 07:19
0

Delphi changes the CPU bitness which .NET does not allow. It throws exceptions for overflows of some kind. Try something like this from the Delphi side:

var lSave: Word;


lSave := Get8087CW;

Set8087CW($037f);

<YOURCALLTO.NET>

Set8087CW(lSave);
Carlo Kok
  • 1,128
  • 5
  • 14
0

It seems Microsoft has fixed this problem by themselves. The problem is gone if you install the latest fixes to Windows 8 available on Windows Update.

Cactus99
  • 11
  • 3