• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • PB2019R3 application crash, faulting module pbdwe.dll or pbtheme.dll, error code 0xc000041d or 0xc0000005

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

Resolved PB2019R3 application crash, faulting module pbdwe.dll or pbtheme.dll, error code 0xc000041d or 0xc0000005

  1. Issue
0
Votes
Undo
  1. Hakan Verimli
    Hakan Verimli
  2. PowerBuilder
  3. Thursday, 16 June 2022 14:16 PM UTC

We are struggling with some apparently-random crashes in our PB2019_R3 application Windows 10 clients.

In addition to being random, not all clients are reporting this issue. 

The faulting module is either pbdwe.dll or pbtheme.dll. Error code is either 0xc000041d (which translates most likely to "An unhandled exception was encountered during a user callback") or 0xc0000005 (which translates most likely to "Access violation"). 

Runtime version 19.2.0.2670.

I have looked into other posts here with regards to the error codes mentioned above. Magnifier does not cause the application crash in our case. Neither do other cases apply. 

We have tried to run the .exe in compatibility mode in windows 8, did not seem to help.

Is there any one with the knowledge of internals of pbdwe.dll or pbtheme.dll to point in which direction we should move us to localize and eliminate the culprit here? Is there any way to localize method name, or such?

Any suggestions on how we could proceed with troubleshooting this? 

PowerBuilder EXE Not Using Specified Icon
zoom maps property using eon_mobile_map object
Responses (3)
Hakan Verimli
Hakan Verimli Accepted Answer Pending Moderation
  1. Wednesday, 6 July 2022 16:49 PM UTC
  2. PowerBuilder
  3. # 1

I have now spend some time with the crash dumps. Is there any symbol files for pb* dlls? WinDbg would like to have symbol files for e.g. pbvm.dll, pbshr.dll, but seems to get some information without them. 

I am very interested in what in dwTableAggrSortCmp can cause APPLICATION_FAULT_NULL_CLASS_PTR_READ_INVALID_POINTER_READ_NOSOS, or FATAL_USER_CALLBACK_EXCEPTION. Hoping that it could shed a light in the right direction.

It looks like both exceptions (0xc0000005, and 0xc000041d) have same call stack. 

Reason I am interested in this is according to WinDbg, the call stack seems like this when the exception occurs:

pbdwe!dwTableAggrSortCmp+0x12479
pbdwe!dwSyntaxFromSQL+0x22a14
pbdwe!dwTableSortCmp+0x1071
pbdwe!CreateXHTMLTemplate+0x10bde
pbdwe!dwSetTransparency+0x276b
pbvm!fnRetrieve+0x366
pbvm!ob_get_global_func_class+0x1dbd
pbvm!ob_get_global_func_class+0x1943
pbvm!ob_create_interface_in_library+0x14bb
pbvm!ot_dbg_funccall+0x5c0
pbvm!getVtableInfo_plugincontextkeyword+0x25f19
pbvm!ob_get_pcode_stack_effect+0xa27
pbvm!ob_get_global_func_class+0x2232
pbvm!ob_get_global_func_class+0x1943
pbvm!ob_create_interface_in_library+0x14bb
pbvm!ot_dbg_funccall+0x5c0
pbvm!getVtableInfo_plugincontextkeyword+0x25f19
pbvm!ob_get_pcode_stack_effect+0xa27
pbvm!rt_hit_level_0+0xaeb
pbvm!rtRoutineExec+0x306
pbvm!fn_txnservice_create_instance+0xa1c4
pbvm!fn_txnservice_create_instance+0x719c
pbvm!fn_txnservice_create_instance+0x679a
pbvm!fn_txnservice_create_instance+0x69c8
pbvm!FN_WindowWnd+0x293f
user32!_InternalCallWinProc+0x2b
user32!UserCallWinProcCheckWow+0x33a
user32!CallWindowProcAorW+0x7f
user32!CallWindowProcW+0x1b
apphelp!DWM8AND16BitHook_CallWindowProcW+0x2a
pbshr!PBC_MainProc3D+0x530
user32!_InternalCallWinProc+0x2b
user32!UserCallWinProcCheckWow+0x33a
user32!DispatchClientMessage+0xea
user32!__fnDWORD+0x3f
ntdll!KiUserCallbackDispatcher+0x4d
win32u!NtUserMessageCall+0xc
user32!SendMessageWorker+0x9ab
user32!SendMessageW+0x6f
pbshr!PBPropertySheet+0x1fb7
pbshr!PBPropertySheet+0x4eb8
pbshr!PBPropertySheet+0x5497
pbshr!PBPropertySheet+0x774d
pbshr!PBTCProc+0xa5
user32!_InternalCallWinProc+0x2b
user32!UserCallWinProcCheckWow+0x33a
user32!CallWindowProcAorW+0x7f
user32!CallWindowProcW+0x1b
apphelp!DWM8AND16BitHook_CallWindowProcW+0x2a
pbshr!PBC_NormalProc3D+0x8a
user32!_InternalCallWinProc+0x2b
user32!UserCallWinProcCheckWow+0x33a
user32!CallWindowProcAorW+0x7f
user32!CallWindowProcW+0x1b
apphelp!DWM8AND16BitHook_CallWindowProcW+0x2a
pbvm!fn_txnservice_create_instance+0x6e3e
pbvm!fn_txnservice_create_instance+0x6a89
pbvm!FN_TabControlWnd+0x405
user32!_InternalCallWinProc+0x2b
user32!UserCallWinProcCheckWow+0x33a
user32!DispatchMessageWorker+0x22a
user32!DispatchMessageW+0x10
pbvm!FN_RunSetHelperWindow+0x670
pbvm!ob_deactivate_session+0x35f
pbvm!ob_run_dispatch_loop+0xdf
pbvm!FN_PluginPollLoop+0x1a2
pbvm!FN_RunExecutableEx+0x78d
pbvm!FN_RunExecutable+0x5c
Application60+0x22b1
Application60+0xa261
kernel32!BaseThreadInitThunk+0x19
ntdll!__RtlUserThreadStart+0x2f
ntdll!_RtlUserThreadStart+0x1b

Comment
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Friday, 17 June 2022 14:01 PM UTC
  2. PowerBuilder
  3. # 2

My first thought is to deploy EVERY DLL that comes with the runtime version of PB and see if that resolves the issue as it's possibly a missing DLL that is causing the problem. I know you said the crash is random. Still, doing this eliminates a primary source of abends.

Comment
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 16 June 2022 15:29 PM UTC
  2. PowerBuilder
  3. # 3

In your PB.INI that is deployed with your app, please try the following:

[Data Window]
Accessibility=0

[DataStore Behavior]
UseHwnd=no

Here is full documentation on the PB.INI options: https://docs.appeon.com/pb2022/pbug/PBINI_settings.html

Comment
Load more comments
Hakan Verimli
  1. Hakan Verimli
  2. Monday, 20 June 2022 15:31 PM UTC
Hi Armeen, Thanks for information, I have passed over your recommendation with pb.ini to users experiencing this issue, awaiting their response.
  1. Helpful
Hakan Verimli
  1. Hakan Verimli
  2. Tuesday, 28 June 2022 14:09 PM UTC
This has not resolved the issue. It still crashes. Any other pointers?
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Tuesday, 28 June 2022 14:29 PM UTC
I would compare Windows OS settings between machines that crash and machines never crash. I think it is environment issue/conflict.
  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.