I have one executable. Exe is prepared from Delphi version 5 as code is written in Delphi. This exe working successfully on Windows XP, Windows 7 with 32 bit operating system. But same executable not working on Windows 7 with 64 bit operating system. It will throw following error code Exception code: 0xc0000005.
The only option is to re compile the Delphi code and make it compatible to Windows 7 64 bit operating system.
I have Google but do not find any suitable article. Therefore, can someone please help me out to resolve this issue.
I have good idea to make executable compatible for 32 and 64 bit but only in .NET Framework. So Please help me.
That error code is the NTSTATUS code for an access violation. For you to see that error code typically means that your application has raised an access violation during initialization. Once the Delphi RTL has initialized then those errors are converted into native Delphi EAccessViolation errors. So with high probability this is an error during initialization, possibly related to the way you link to or use a dependent module.
In order to solve the problem you need to do some debugging. The first thing I would do is to use Dependency Walker in profile mode to run your application. This will give you diagnostics of the load of your process at some point, presumably during the load an initialization of a module, you will see an error. Hopefully this will lead you to a solution.
Programs built with Delphi 5 do run on 64 bit Windows. You have an error in your program that needs debugging. Simple as that. Not the easiest error to debug, but it's still just a debugging exercise with your code.
Related
I installed the latest Chromium Embbed version on XE6, did a test using demo guiclient and worked very well. But when I create a new app and put TChromium component receive this error:
I did the tips on this question.
Usually that means that a 32 bit process is attempting to load a 64 bit module, or vice versa. You need to do a bit of debugging, for instance using Dependency Viewer, to work out which module has the wrong bitness.
One obvious possibility is that your host process is 64 bit and the CEF libraries are 32 bit. To fix that you would need to switch your process to be 32 bit, or find 64 bit CEF libraries. I'm not even sure if the latter exist.
I am trying to port an unmanaged C++ Dll from one embedded device to another and am facing some strange problems which I think must have something to do with memorymanagement and/or compilers. I am not posting much code but describe what I tried as I have tried too many different things to post all code and I think the problem must be somewhere deeper within.
The first device is running WinCE 5.0 and is compiled using embedded Visual C++ 4.0.
The second device is running Windows Embedded Compact 7 (I will call it WinCE 7 for simplicity) and is compiled using VS2008. Both devices have their own SDKs designed for the boards.
On the first device the Dll is running without any problems, but on the second device the with ne new SDK compiled Dll is not working. Having a C# applikation on the second device I tryed PInvoke to access the dll but on the PInvoke line in Debug Mode got the error message:
Can't find PInvoke DLL NAME.dll
After some research I learnd this error can have differend causes:
Missing dependencies of the native library you are calling into.
The native assmebly was compiled for the wrong subsystem (i.e. desktop, not CE)
The native assembly was compiled for the wrong processor (i.e. x86 and not ARM)
Not enough virtual memory for the DLL to load.
I used peinfo to check the dll. All dependencies are being found on the device, it is compiled for WinCE 7 and the processor type is right. (I would have been surprised if not, using the right SDK) So there still is number 4: not enough virtual memory. But WinCE5 is limited to 32MB virtual memory and running while WinCE7 can have up to 2GB?
So I started to try some things to narrow the error in and will tell you my results.
First I took my dll compiled for the first device and tryed to use it on the second device. Surprisingly the .net application can find and PInvoke this one. But some functions inside the Dll don't seem to be running right so I guess I have to use the right SDK. But having the right code for both dll I know the exports must be right. I am aware the two compilers use different c++ name mangling styles so that is not the problem, too.
Next I wrote a simple c++ application on VS2008 using the new SDK to Load the Dll from there. On the first device the application runs this way but now on my remote Display on running on the second device I get the Error Message:
Unable to import library NAME.dll ! Program will exit.
At least now I know it has nothing to do with .net and PInvoke. But further on I made a simple new dll using VS2008 and the new SDK and ne .net application is able to PInvoke it. So there must be something in the code that doesn't like to be Loaded. :-/
After some hours of searching through the code I realised the system doesn't like some global variables. I know global variables are bad and I would be glad if they wouldn't be there, but I have not started the code and over the years they got more and more before me dealing with it, so they would be very hard to erase right now.
These globals are instances of classes. Some of them seem to be bad, some others seem to be ok. Confusingly they all are instances of classes and I don't know why there are good and bad ones. When I comment out the bad globals, the application is able to PInvoke the Dll. One of the bad globals is enough to make to applikation not find the Dll.
Why is it like this using VS2008 with WinCE 7 but not using eVC4.0 with WinCE 5? And what is the problem with the globals? How can I solve this problem? At best the same code should be working for both compilers but first I need some ideas, what is wrong with the second compiler.
I have found the solution to my Dll loading problem. The two systems have a different behaviour on #pragma pack. So eventually there was missalignment while loading the dll what made the dll crash. Because of the globals it was in the loading process of the dll, so the error message did not say something about missalignment but the standard "Can't find PInvoke DLL".
I have developed a Delphi application (XE4) on a Windows XP machine.
When I copy all the project files to a Win 7 machine (also Delphi XE4) it will not compile.
The source has uses Vcl.Grids and the compiler complains it can't find vcl.grids.dcu.
Changing to uses grids works but I don't want to edit all the source.
I've checked the Embarcadero website for information on Namespaces but couldn't find anything useful.
I know it's possible to say uses vcl.grids under Win 7 so there must be some setting somewhere in the project that is preventing the resolution.
I've tried deleting the dproj files but that had no effect.
How do I get the source to compile with minimal changes?
The error has nothing to do with OS. It means your IDE/Projects's search paths are not configured correctly, or your project is missing references to the relevant packages, so double check that.
Also, you can use uses Grids in the code, and then make sure Vcl is listed in the Unit scope names field in the Project Options.
The information that you describe seems to be erroneous. The compiler is not affected by the operating system on which it runs. Running the same compiler on the same source code on a different operating system does not result in compiler errors.
Here are the reasonable explanations for your problem:
You are compiling the code on different versions of the compiler. Your error message matches what happens when you compile modern namespace aware code on XE or earlier.
Your are not compiling the same source code on both machines.
It is extremely hard to see beyond these two explanations.
Ok, red face time. Turns out I was running an earlier version of Delphi on the Win 7 machine. Delphi XE4 was installed along with an earlier version and I was invoking the earlier version.
Once I actually brought up XE4 on the Win 7 machine the issue vanished.
So I will don a hair shirt and crawl under my rock.
Thanks everyone who contributed.
We ported an application from Delphi 7 over to Delphi 2010 and have had customers encountering intermittent BSOD (blue screen of death) errors while running under Windows XP. The errors are very sporadic and have been very hard to track down. FYI : We are using the built-in memory manager from Delphi 2010.
Our first thought was a hardware issue but upgrading system drivers failed to fix the problem.
Has anyone else encountered BSOD issues under XP with Delphi 2010 generated applications? If so, do you have any suggestions on how we might correct this problem?
Thanks for your assistance!
There's nothing in the Delphi core libraries that can cause a BSOD directly. As David pointed out, Delphi programs run in user space. However, if they're sending invalid data to a kernel-space driver, that's a different matter.
You said D7-D2010 update, and the first thing that occurs to me there is the string revamp. Delphi's standard string type has been changed from AnsiString (1 byte per char) to UnicodeString (2 bytes per char) and if you're sending the wrong type of string to a driver or system routine somewhere it might cause strange behavior.
First thing I'd do is run a full build and watch for "implicit conversion" warnings from the compiler. This means that you're mixing string types. Find these and fix them and see if that helps.
Also, if you have any import units for external libraries, and they use APIs that take a string (or more likely a PChar) parameter, make sure they're converted to PAnsiChar. Delphi's already taken care of this for the Windows API stuff used in windows.pas, but if you've got any of your own you need to take care of it yourself.
BSOD can be analyzed opening the crash dump with WinDbg or other tool able to process crash dumps. Even a "minidump" will give enough informations to try to understand where and hopefully why a BSDO occurs. WinDbg can be downloaded freely, and you don't need to install it on the target machine, you can ask your customers to ship the crash dumps to you, and you can analize them offline. Anyway generating a BSOD from user mode code is usually very difficult - but there are ways to crash a system. What kind of error the BSOD displays?
Update: if the error is PAGE_FAULT_IN_NONPAGED_AREA this link explains what happened: http://technet.microsoft.com/en-us/library/cc957625.aspx. It usually a memory-related issue, and it may be that D2010 using more memory than older version may end up to trigger it. Could you run a memtest on those machines (http://www.memtest.org/)?
Ntkrlnpa.exe is not a driver, is the image containing the OS executive and kernel code (the version with PAE support). Using winDbg and the crash dump it is possibile to obtain the call stack leading to the crash.
HI:
I've a Delphi 7 program that I wrote many years ago, but I've lost the source code. It's a small program but very useful for me.
I've tried to 'install' it again in a new Windows XP computer, just copying the folder with de data (.db paradox files), and configured the BDE connection.
When the programm starts I receive an "Unknown exception" and halts. I've no idea why this happens, and can't debug cause the lost source code. I've tried in another computer with the same results.
Any suggestions or ideas? What do you do in a situation like this?
Thanks in advance.
EDIT:
When I installed Delphi 7 in the new XP computer, the exception came from unknown to known. It was something related to the folder for the Paradox.net file. Thnk you all.
Delphi IDE can attach to a running process and debug it (Run -> Attach to process), although without debug symbols you will end up debugging plain assembler code, which requires some knowledge of assembler and how a Windows application works. And debugging startup exceptions could be pretty difficult if the debugger can't start the program. You can also use the WinDbg debugger from Microsoft.
There are disassemblers (I used the very powerful IDA Pro) that are able to recognize standard library calls helping analysys a lot. You may also find decompilers, although decompiling native applications is a bit more difficult than with those using a p-code or the like.
If the error is not due to a misconfiguration, patching a binary file is not easy.
You can use any debugger, either Visual Studio one, or a free OllyDbg, don't know if Delphi IDE have a simple external-exe-debugger.
But debugging will be very hard w/o source codes, and you must have at least basic knowledge of Assembler Language and win32api.
Alternatively you can use tools like FileMon & RegMon to examine your app activity and find potential problems.
You can try "Run|Connect to process..." in the Delphi IDE. But what zed_0xff said regarding debbugging without sources still applies.
I would go for the disassemble approach like ldsandon suggest, especially since you have (some) knowledge about what your exe is doing.
Besides IDA Pro also take a look at tools aimed specifically at Delphi such as IDR (Interactive Delphi Reconstructor), DeDe and PE Explorer.
To make sure it is not BDE related, I would build another rudimentary application trying to access the same data on this machine.
Once this application works, you can move on to test on the Pascal code side of things.
I have had my share of BDE oddities so I'd prefer to rule this out.