4

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!

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Jeff Cope
  • 781
  • 2
  • 7
  • 15
  • I have seen issues with Delphi's memory management and DEP in Windows that resulted in lots of strange OS errors. Setting /noexecute=alwaysoff or adding an exception for the app alleviated the issue. – gordy Jul 11 '11 at 20:07
  • 7
    The problem is with a device driver or the hardware. Delphi apps run in user space and don't cause kernel faults. – David Heffernan Jul 11 '11 at 20:14
  • @Gordy: What version? The last few versions of Delphi come with the FastMM memory manager, which fixes the correctness issues that were in Borland MM. – Mason Wheeler Jul 11 '11 at 20:43
  • What service pack has the XP machines installed? –  Jul 11 '11 at 20:44
  • @Mason Wheeler: D2007, toggling DEP and testing might be worth OP's couple of minutes although it doesn't sound like the issue is consistently reproducible. – gordy Jul 11 '11 at 22:08
  • @gordy - As far as being reproducable, it is and it isn't. It's not consistent in that it's always the same options that make it fail but fails pretty frequently meaning it may happen after they've been in the application for an hour or so or maybe after 4 or 5 hours but it's an almost guarantee that it's going to happen by the end of the day. Even here in our office on our machines in addition to the client site where we were beta testing the Delphi 2010 version. It would be nice if we could pinpoint a certain process/option to narrow down what we are looking at. –  Jul 12 '11 at 12:58
  • @Ann: the best way to pinpoint the problem is to analize the memory dump with WinDbg and get the stack trace causing the problem. If you can find a tool to generate MS symbols files from Delphi 2010 .map files you can easily see the functions called. Otherwise it could be a long and tedious procedure. –  Jul 13 '11 at 15:51

2 Answers2

6

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.

Mason Wheeler
  • 82,511
  • 50
  • 270
  • 477
  • 6
    +1 - It still points to a kernel-level/driver bug. Sending invalid data shouldn't cause a BSOD, the fault should filter back up to the user application. Also (for the OP): If you do this, make sure you double check all your units (and 3rd party components) to ensure that they aren't hiding the warnings! – afrazier Jul 11 '11 at 20:37
  • 1
    I have seen a user mode application consistently crash NT4 on multiple machines in the past - and the app was MS Word (95 or 97) when loading a corrupt doc file! – Gerry Coll Jul 12 '11 at 00:10
  • @Gerry: It's a semantic issue. User mode code cannot crash the OS, only kernel mode code can. But the user mode code can definitely do things which invoke kernel mode routines, which can lead to a crash. – Mason Wheeler Jul 12 '11 at 00:13
  • @Gerry XP is a long way from NT4. – David Heffernan Jul 12 '11 at 06:25
  • @David - I know that. I just thought it was weird at the time. It would have been good to have had the time and tools to investigate it back then. It was more of an anecdote really. – Gerry Coll Jul 12 '11 at 08:14
  • What Mason wheeler said. Opengl, USB using DLLs are all typical cases. An extreme case was a display driver that didn't handle extreme coordinates (outside say a 200 pixel rim around the screen) very well. If you vigorously dragged, you could get into coordinate regions that caused crashes. – Marco van de Voort Jul 12 '11 at 09:55
  • Oh, and btw, we did address all our implicit conversion warnings in both the D7 & D2010 versions. Hasn't made a difference. We still get the BSOD error. Same exact one. – Jeff Cope Aug 04 '11 at 14:41
3

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.

  • The BSOD error is "PAGE_FAULT_IN_NONPAGED_AREA" caused by driver ntkrnlpa.exe. It only seems to occur on Windows XP machines. They are on SP 3. I believe this to be true of all of them that have experienced this problem but would have to double verify. These same workstations run the Delphi 7 version just fine. It's only the version ported over to Delphi 2010 that fails. We are currently looking into the "implicit conversion" warnings and addressing those (we don't have many). Then we will proceed to check out our 3rd party vendor components. –  Jul 12 '11 at 12:58
  • We did the memory test and only 1 machine showed a problem during one phase of the memory test. All others were ok. We have upgraded one of our components and have resolved all our implicit casts (although we didn’t have many) and found none that seemed incorrect or suspicious. We will be doing further testing and post our progress once it’s known. – Jeff Cope Jul 13 '11 at 13:55
  • Did you try to analize a dump? It will give you precious informations directly from the problem root. –  Jul 13 '11 at 15:51
  • Ok, I really don't know what I'm looking at and I'm limited on what I can include here but using WinDbg I get the following: PAGE_FAULT_IN_NONPAGED_AREA (50), FAULTING_IP: win32k!NtGdiModifyWorldTransform+a6. Graphics issue? It's only a problem under Windows XP mind you and the Delphi 7 version of the same code doesn't have a problem. We don't do any graphics programming on our own. Any ideas? – Jeff Cope Aug 04 '11 at 14:04