• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • How to read and interpret .dmp files created by a PowerBuilder app crash?

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved How to read and interpret .dmp files created by a PowerBuilder app crash?

  1. How-to
0
Votes
Undo
  1. Igor Perisic
    Igor Perisic
  2. PowerBuilder
  3. Wednesday, 9 November 2022 17:25 PM UTC

Hi, 

I'm not sure if this is the right place to ask for help regarding .dmp files. I have one app in production that crashes once in a blue moon and I can't reproduce it because I don't know what causes this type of crash. Which is what lead me to read the .dmp files created by this PB app crash. My goal is to pinpoint exactly where this error is occurring and why to prevent future crashes. 

I used WinDbg to read and analyze the file but I'm not sure what some of the things mean, especially the Stack Trace. The Stack Trace has almost 40 lines and not sure how to read it but I won't include the whole stack trace for now. 

These are some of the things displayed inside the .dmp file. 

EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 0000000075d2dd2d (pbvm!ob_get_runtime_class+0x00000000000000ad)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. (I'm not sure what 0x%p and %s mean )

STACK_COMMAND: ~0s; .ecxr ; kb

SYMBOL_NAME: pbvm+ad

MODULE_NAME: pbvm

IMAGE_NAME: pbvm.dll

FAILURE_BUCKET_ID: NULL_POINTER_READ_c0000005_pbvm.dll!Unknown

OS_VERSION: 10.0.14393.5125

BUILDLAB_STR: rs1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

IMAGE_VERSION: 21.0.0.1509

FAILURE_ID_HASH: {3b246f68-a22f-b7a3-94ac-e20135924ef9}

Followup: MachineOwner

 

Microsoft website displays what the Access Violation C0000005 is. "The first Exception Parameter (0) is the type of the violation; Read (0), Write (1) or Execute (8). The second Exception Parameter (1) is the address of the violation." So because my Parameter[0] is 000...000 this means the violation is a Read (0)? and Because my Parameter[1] is also 000...000 this means the address of the violation is nonexistent? 

 

Could reading the 40 lines of the Stack_Text help me understand this error more, as in, in which PB function this crash occurred, which file it's trying to read, etc? And How could I even begin interpreting the stack text lines like this

"00000000`00efca10 00000000`75d7fa46     : 00000000`10df1ae0 00000000`0dd62828 00000000`04970000 00000000`10e00388 : pbvm!ob_get_runtime_class+0xad"

Again I'm not sure if this is something the Appeon community can help me with even though it's a PowerBuilder app that produced a .dmp file but if anyone could help me or point me in the right direction I'd really appreciate it. 

  1. Crash
  2. PowerBuilder
Validate Email
JWE
Responses (3)
Francisco Martinez @Appeon
Francisco Martinez @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 9 November 2022 17:38 PM UTC
  2. PowerBuilder
  3. # 1

Hi Igor,

Address 0x00000000 doesn't mean a non-existing address. It most likely refers to a pointer initialized (or reset) to nullptr (or NULL). So basically, somewhere it was attempted to dereference a null pointer.

Just my 2 cents

 

Regards,
Francisco

Comment
Igor Perisic
  1. Igor Perisic
  2. Wednesday, 9 November 2022 17:47 PM UTC
Your 2 cents actually make a lot of sense, thanks! Now I just need to figure out where it attempted to dereference a null pointer..
  1. Helpful
Francisco Martinez @Appeon
  1. Francisco Martinez @Appeon
  2. Wednesday, 9 November 2022 19:04 PM UTC
I don't think you're going to find that, the exception was raised from the pbvm.dll file. Meaning there's something going on with your program that's causing the PB runtime to crash. Your best bet would be to single out the crash and create a reproducible case such that the development team can analyze it with more advanced tools. (e.g. debugging PowerBuilder itself)



Regards, Francisco
  1. Helpful 2
Igor Perisic
  1. Igor Perisic
  2. Thursday, 10 November 2022 16:19 PM UTC
The app is huge so reproducing this exact error would take weeks. Is it possible to include labels inside the PB app some how so that the crash log (.dmp) contains some sort of marker, like what function was it in, or any sort of marker that would help us determine where the program is when the crash occurred? If so that would be very helpful for future crashes.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 10 November 2022 01:17 AM UTC
  2. PowerBuilder
  3. # 2

Did you check the windows Event Viewer when the crash happens? Maybe there's some information there too?

Comment
Igor Perisic
  1. Igor Perisic
  2. Thursday, 10 November 2022 16:13 PM UTC
I did not, I was given the dump log by someone else. This app is running on our production VM and I don't have access to that, so I can't really explore the system the crash happened on.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 10 November 2022 16:22 PM UTC
That's as shame, maybe you can ask "someone else" to look at the event logs whenever a crash happens.

regards.
  1. Helpful
Igor Perisic
  1. Igor Perisic
  2. Thursday, 10 November 2022 17:36 PM UTC
I'll do that for future crashes but the only problem is this crash happens every once in a while, so it could be a few weeks before it happens again. But this crash is something I need to figure out as soon as possible. That's why my hopes are to find some useful information inside this .dmp file. Do you know if I could include some sort of marker (any sort of marker) inside my app to help us determine where the program is when the crash occurred for future crashes?
  1. Helpful
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Thursday, 10 November 2022 22:33 PM UTC
  2. PowerBuilder
  3. # 3

This is where adding a LOG file to your code comes in handy, and the bigger the code the MORE handy the log file becomes.

At the very least, put code in the ancestor objects logging that you ENTERED the event or function and that you are LEAVING the event or function.

Even in huge applications, this is a relatively easy and quick addition to make. Then recompile and test the logging. When you get it working it will leave a trail that you have use to see where you are crashing. As the need expands, you can add to your logging at various levels, including the descendant (if you wish). You can capture parameters, variables, whatever is needed.

This might be the only way to track what's occurring in your app.


Good Luck,

Olan

Comment
Igor Perisic
  1. Igor Perisic
  2. Wednesday, 23 November 2022 18:37 PM UTC
We use this type of logging for smaller apps, but this specific app is very complex and has a lot of functions and code. This app would take weeks of running to reproduce a crash as it happens 1 in 10-20 million transactions. It would fill the hard drive with log entries way before we might actually get one of these errors.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.