Windows10 - AECOSIM/Bentley Product VBA scripts fail

We run a Army Secured Operating system environment with many STIG policies applied. We are finding that the VBA scrips crash Bentley products when we run them. simple example mvba files up to AECOSim BD tools.

We are looking for some direction on what to look for and why this is happening in order to work with our AD/Group Policy team to test a solution and identify the risks of any solutions.

Thank You,

Brian Dinnon

Parents
  • To set a baseline for the what type of problem may be occurring, I suggest the following items be performed individually in the order listed to help identify or resolve the issue(s):

    1. Most new product installs may require a reboot if certain application or common files were open at time of install.  Microsoft SysInternals: PendMoves is a convenient way to validate if a reboot is required.
    2. Most new software deployments do not run under a given user's context and may on first start for a given user, require to Run As Administrator to ensure all application resources needed (files, registry, startup, permissions, etc.) are allowed to fully be set for a given (possibly restricted access) user
    3. If no Reboot is required and Run As Administrator do not correct installer and deployment related issues, you can check and validate application/user and/or file and registry: access permissions, rights, and file existence and locations using; Microsoft Process Monitor (procmon).  Record the full start of a process up to the point of an error, save "All Events" as a .PML file extension, and use Process Monitor's very effective filter system looking for result and detail information containing "access" or "permission", and other file related hints towards incorrect or "not found" files and folders needed.
    4. If the above items have not helped pinpoint the problem and the problem is an "exception" or "crash", then capturing a Microsoft DebugDiag full memory dump of the application, zipped and sent to the appropriate product support team for review should provide very specific details to either: a.) provide an indication of what went wrong and how to configure/change the outcome, b.) provide an alternative work-around, or c.) require some additional logging to help intersect a more elusive problem, or d.) result in a product defect being filed to address the (confident) found issue with a code fix for a future release where the issue could be resolved.

    HTH,
    Bob



Reply
  • To set a baseline for the what type of problem may be occurring, I suggest the following items be performed individually in the order listed to help identify or resolve the issue(s):

    1. Most new product installs may require a reboot if certain application or common files were open at time of install.  Microsoft SysInternals: PendMoves is a convenient way to validate if a reboot is required.
    2. Most new software deployments do not run under a given user's context and may on first start for a given user, require to Run As Administrator to ensure all application resources needed (files, registry, startup, permissions, etc.) are allowed to fully be set for a given (possibly restricted access) user
    3. If no Reboot is required and Run As Administrator do not correct installer and deployment related issues, you can check and validate application/user and/or file and registry: access permissions, rights, and file existence and locations using; Microsoft Process Monitor (procmon).  Record the full start of a process up to the point of an error, save "All Events" as a .PML file extension, and use Process Monitor's very effective filter system looking for result and detail information containing "access" or "permission", and other file related hints towards incorrect or "not found" files and folders needed.
    4. If the above items have not helped pinpoint the problem and the problem is an "exception" or "crash", then capturing a Microsoft DebugDiag full memory dump of the application, zipped and sent to the appropriate product support team for review should provide very specific details to either: a.) provide an indication of what went wrong and how to configure/change the outcome, b.) provide an alternative work-around, or c.) require some additional logging to help intersect a more elusive problem, or d.) result in a product defect being filed to address the (confident) found issue with a code fix for a future release where the issue could be resolved.

    HTH,
    Bob



Children
No Data