1. Miller Rhodes
  2. PowerBuilder
  3. Monday, 15 June 2020 16:51 PM UTC

I am running Powerbuilder 2019 R1 Build 2170 at a customer currently and haven't had any problems until now.

I am using a Windows 10 VDI ( remote virtual desktop ) to do my work and I believe that the technical team

for my customer released some sort of change that affected my Powerbuilder deploys.

Everything works fine in the IDE and it is business as usual. However, as soon as I deploy the application to an EXe with PBDs then the application fails to execute.  This has been working for months.

 

Here is what the Event Viewer tells me:

Faulting application name: admin_utils.exe, version: 2.0.0.0, time stamp: 0x5e03ac98
Faulting module name: pbdwe190.dll, version: 19.0.0.2170, time stamp: 0x5e03ae9a
Exception code: 0xc000041d
Fault offset: 0x00251a1c
Faulting process id: 0x2020
Faulting application start time: 0x01d64333e2f904bc
Faulting application path: C:\AdminUtils527\admin_utils.exe
Faulting module path: C:\AdminUtils527\pbdwe190.dll
Report Id: 6d5ef551-1be9-440d-be84-8bba81827d20
Faulting package full name:
Faulting package-relative application ID:

I can gather data from anywhere else you suggest..

 

Miller Rhodes Accepted Answer Pending Moderation
  1. Monday, 15 June 2020 18:58 PM UTC
  2. PowerBuilder
  3. # 1

New Info,

 

If I "run my EXE as administrator" everything works fine.

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 15 June 2020 20:13 PM UTC
  2. PowerBuilder
  3. # 2

Hi Miller;

   The module that is having the issue is the pbdwe190 - where DWE is the Data Window Expression evaluator. Obviously, since the App works OK in ADMIN mode, its most likely a "permissions" issue.

Q: Do you compile in a default Manifest into you APP.exe?

For example (from Project Object) ...

Regards ... Chris

Comment
  1. Thomas Rolseth
  2. Monday, 5 October 2020 22:45 PM UTC
I'm having the same exact problem. Any window with a datawindow control on it (even with an external dw with no rows) will halt and crash the application. It works fine from the PB IDE, from the cmd prompt, running as admin, running from windows search and running via a batch file. But those are not viable options as the client wants the user to just double-click the exe like they always have. I've tried using Embedded Manifest in the project object. If the execution level is 'As Invoker' it still does not work. If the execution level is 'Highest Available' it works but the user is prompted for an admin userid and password -- not ideal.



I've also created a shortcut and set the compatibility to Windows 8 -- still no luck.



The windows event viewer says the faulting module is pbdwe190.dll -- could that dll be corrupted somehow? Seems like it would never work if that was the case.
  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 5 October 2020 22:58 PM UTC
Hi Thomas;

Sounds like either a Microsoft KB update or a change to the PC environment (ie: AV, AD, Windows Persmissions, etc). You might want to follow through with your customers any what recent changes to their environment have been. Food for thought.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Miller Rhodes Accepted Answer Pending Moderation
  1. Monday, 15 June 2020 20:20 PM UTC
  2. PowerBuilder
  3. # 3

Hi Chris,

This is what my project file looks like on that tab

 

Comment
  1. Miller Rhodes
  2. Monday, 15 June 2020 20:38 PM UTC
Thank you Chris



I tried Embedded manifest As Invoker and still have the same problem...crazy

  1. Helpful
  1. Chris Pollach @Appeon
  2. Monday, 15 June 2020 23:21 PM UTC
That normally does it for my Apps on W0 unless, the environment has tighter "policies". Then you might have to use an "External Manifest" that is tuned to your production environment - "rights" wise.

The other thing that has also worked for me besides the manifest route is to use W10's "Troubleshoot Compatibility" wizard (RHMB on the App's EXE). Sometimes for certain W10 environments, I have to run the EXE in W 8.1 / 8 or even 7 compatibility mode for it to work OK. Rare - but for some odd reason, a necessity. Another "food for thought".
  1. Helpful
  1. Miller Rhodes
  2. Monday, 15 June 2020 23:35 PM UTC
Great points Chris. Much appreciated! I will go try some of these things and report back
  1. Helpful
There are no comments made yet.
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 16 June 2020 09:29 AM UTC
  2. PowerBuilder
  3. # 4

Hi  Miller,

This is probably due to the changes in the Windows environment. However, we are not clear what is the root cause of it, maybe it is related to the Windows security settings.

At present, I suggest you:

  1. Use Run as administrator to launch the EXE.
  2. Right-click the EXE file and select ‘Troubleshooting Compatibility’ to launch it.
  3. Create a bat file and run the EXE via bat.

 

Regards,

Ken

Comment
There are no comments made yet.
Thomas Rolseth Accepted Answer Pending Moderation
  1. Tuesday, 6 October 2020 18:45 PM UTC
  2. PowerBuilder
  3. # 5

FWIW, attached are some logs from Process Monitor that show where things start to breakdown.  The 'cmd' version shows the log activity of the application (fr.exe) running successfully using the command prompt.  The 'explorer' version is the activity for the application when you double-click the exe in file explorer.  Things start to diverge at line 62.  In the 'cmd' log, it starts reading the registry for international time and date settings whereas the 'explorer' version skips that entirely and the thread exits after a fault is thrown. 

Attachments (1)
Comment
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.