Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 670
  • Last Modified:

Delphi 7 DLL crashes .NET application in 64 bit Windows

Hello Experts,

I have a DLL written in Delphi 7 that is being called from a .NET application. The .NET application has been written in Visual Studio 2005 and uses .NET 3.0.

The DLL exports several functions, most of them do math calculations, one or two draw some graphs using Win32 graphic functions into an internal buffer.

The DLL and the .NET application has been running successfully for the past year in Windows XP 32 bit.

Recently the client has updated his systems to Windows XP 64 bit and we've ran into a problem.

The DLL and his .NET application run fine. However, when the .NET application is closed, it crashes with an error message.

What is the reason for this error, and what are possible fixes for it?

Please don't hesitate to ask any additional questions if you need more information. Thank you.

Sincerely,
Catalin Ionescu
0
heatseeker
Asked:
heatseeker
  • 3
  • 3
1 Solution
 
developmentguruPresidentCommented:
 When you say "it crashes" I could use more info.  Does it give you an error and shut down?  Does it give you the error and then (hang) stay in memory?  What is the error message?  Does your DLL use any COM objects?

  When I have run into something not shutting down in the past I have seen one common cause that comes to mind.  If you are using COM objects, and they are not all disposed of (use count = 0) on closing the application, then Windows will wait patiently (IE: forever) for the COM objects to be freed before allowing the application (or in this case DLL) to shut down.  It uses WAITFORSINGLEOBJECT which can wait for a DLL or COM object to be released.  If this is not your issue, I will definitely need more information.
0
 
heatseekerAuthor Commented:
Thank you for your answer.

Here are more details... It is not a COM object. It is a simple DLL that exports 5 functions. The functions are exported using stdcall convention. All functions but one have simple type parameters (integers, doubles) and the remaining one has one parameter as a pointer to an array of integers. The size of this array is specified in a separate parameter.

The entire DLL works just fine with the same .NET application if ran under Windows XP professional 32 bit.

Regarding the crash, it is an error message given by the .NET application when the application is closed by the user, only if ran in Windows XP professional 64 bit.

I do not have the exact error message, since I don't have an environment to test it myself and the client didn't specify the exact message. However I believe the message has something to do with an illegal code or referencing an illegal memory area. The message appears when the application is closed, not when it runs. If within the application there are no calls to my DLL functions, there is no error message.

Any ideas what could cause this? The application has ran successfully for approximately 1 year on Windows XP 32 bit, and the errors started showing up only when the client migrated to Windows XP 64 bit.

Thanks.

Sincerely,
Catalin Ionescu
0
 
developmentguruPresidentCommented:
 Honestly I would recompile the DLL with EurekaLog and let it tell you where the error is happening.  EurekaLog will send you an email from their machine showing not only where the error occurred, but also the entire call stack that led to it.  It is an invaluable tool in situations where the error only happens on the client machine.

  My only guess, without more information, is that you are writing to memory that you should not be.  Memory managers (including Windows memory manager) have a granularity to them.  It is possible that Window 64 bit is throwing an access violation that should have happened in the 32 bit but never did.  If you were to try to allocate 4 bytes of memory in a situation where the granularity of the memory manager was 16 bytes you would get 16 bytes.  In win32 writing to the memory after the 4 bytes (but not past the end of the 16 bytes) would not cause an access viloation.  It is possible that the windows memory manager now sees you writing beyond what you allocated and throws the error.  This is better behavior since it will point out errors in your code.  It would be annoying if it has been working fine prior though.  Odds are good that it is something like this (related to your array).

//assuming the array is a simple in memory array...
for I := 0 to ArrayCount do //should be 0 to ArrayCount - 1
  MyArrayp[I] := 0;

This would cause no problem in one situation and could cause a problem in the other.

Let me know if this helps.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
heatseekerAuthor Commented:
Thank you, I thought a similar problem would be the cause for the error...

I will check EurekaLog and see if it will help. The customer runs the computers into a heavy protected LAN (corporate environment).

One idea would be to change his application slightly to call only the other functions, but not the one dealing with the array of integers. If this doesn't produce an error, we're one step closer to finding the problem and fixing it.

So there would be no other possible issues, like model changes or what not introduced with Windows XP 64 bit that could cause otherwise perfectly valid code to stop running or cause issues?

Sincerely,
Catalin Ionescu
0
 
developmentguruPresidentCommented:
 I had an idea... I just ran into an issue with an older application running on Vista 32 bit.  I was able to get it to run using a compatibility mode.  Windows XP has come compatibility modes too.  Right click on the shortcut / EXE and click on properties, then go to the compatibility tab.  Try selecting to run the program in Windows 2000 compatibility mode.  See if it helps.  This should give you a little more information.  

  I rather strongly suspect that the array access is the problem though.  If, for example, it was your DLL's interface with windows that was flawed then I would expect you to see access violations during execution, not so much after.  Check the DLLs cleanup code especially.
0
 
heatseekerAuthor Commented:
Thank you very much for your time. Your insight into this problem has pointed me into the right direction, and although I haven't yet located nor fixed it, you have put me on the right track.

Again, thanks and A+ for your ideas.

Sincerely,
Catalin Ionescu
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now