[MSCE U17 VBA] Crash without running code

Hi clever_anthony ,

Although there may be other possibilities, my first suspicions are to consider:

1. 3rd party Anti-virus/Anti-malware that may need/require Exclusions for .MVBA file types in one or more specific folders (you designate as safe from the outside world - e.g. your customizations)
2. Location of .MVBA file(s) on a Drive: a.) Mapped as a Network Drive, or b.) Mapped to a Shared File Service.  If "a", it is possible Windows temporarily disconnected (think put to sleep) the resource connection where typically user activity (vs program activity like a save) may be required to wake it properly. If so, then it is possible that you can request that your IT dept increase the connection timeout in the group policies.

If possible, see if you can locate any MicroStation Crash Dump files on your system (.dmp and/or .hdmp) very close in approximation to the time you noticed the exception.

To locate the .dmp/.hdmp files you can try:

1. Check your MicroStation Temp folder:
2. Check your System using a tool like e.g. VoidTools - Search Everything; sorting by date/time modified then Right Click > Open Explore in Folder

If you find any, you can Zip and send them using our Secure Upload option.

HTH,
Bob

Could you please help check if the Dump files were uploaded? I uploaded it without any login.

Hi clever_anthony ,

Being anonymous uploads to ensure a quick and accurate review, can you...

1. Let me know the exact File Name(s) uploaded?
2. Let me know the Date and Time of "the event(s)"?

Thank you in advance,
Bob

I am not sure if that file was uploaded because I could not see any "submit" bottom after upload success.

Robert Hook said:

Let me know the exact File Name(s) uploaded?

The file name should be exception.zip (one zip file)

Robert Hook said:

Let me know the Date and Time of "the event(s)"?

The zip file contains two different date, which should be on 2022-11-28 and 2022-12-07. The crash case should be the same - VBA Text Editor crashed, cannot input text after exception.

On the other hand, may I have any Bentley validation tool to check if the MVBA file is not corrupted? (although it looks fine now)

Hi clever_anthony ,

Thank you. I will take a look at the exceptions in the file noted soon.

As for VBA Validation Tool, in the past we created an internal MicroStation VBA macro that used the VBE (project) APIs by referencing: Microsoft Visual Basic for Applications Extensibility 5.3 (VBE6EXT.OLB).  It simplified (rarely needed) manual steps for a given selected project to:

1. Export all: Forms, Modules, and Classes.
2. Create a New MicroStation VBA Project
3. Import all individually exported: Forms, Modules and Classes

Since the steps above can be done manually and not needed all that often a couple steps I suggest in addition would include:

1. Verify the Imported - Project > References; ensuring no Missing/Unavailable items reported
2. Verify all Project Files (Forms, Modules and Classes) include (no quotes) "Option Explicit" at the top of each File.
3. Verify the Project Compiles: Debug > Compile  (ProjectName)...

The reason the Export/Import steps may be required is because Microsoft component meta associated to Project Files and References can get out of sync and cause things to behave inconsistently (though have not seen any crashes related to such issues) and Export/Import can often fix hard to find inconsistency issues.

The reason to perform the Additional Steps are simply very good Microsoft/MicroStation VBA best practices to perform sanity checks to help ensure consistent and reliable operation.

HTH,
Bob

Hi clever_anthony ,

I still need to find some time to review the dump file provided, however when reviewing the exception.log and with respect to my concern above (#2 - Location of .mvba Files), can you (or the user) consider:

1. Moving any MicroStation VBA macros locally - to see/report if the problem is resolved or persists
2. Setting the MicroStation Configuration Variable MS_VBA_OPEN_IN_MEMORY=ALL to load the (likely remote) .MVBA file into memory. This helps eliminate issues that can arise due to:
   1. Avoid Microsoft IStorage API client limitations, and
   2. Microsoft Configurations and Policies that may place a UNC drive into a sleep/disconnect state after a period of time (e.g. 1hr away for lunch) and only resolved once a user (manually) awakens the specific network mapped drive by clicking on the drive in Windows Explorer.

Exception.log shows "U://" convention being used to locate MicroStation VBA macros:

MS_VBASEARCHDIRECTORIES: WorkSet        = U://;D:\LPM2\Microstation for LPM2\CE\  

HTH,
Bob

Robert Hook said:

Moving any MicroStation VBA macros locally

The VBA marcro was in D:\

There were no mvba files in U://. (I installed Microstation by myself and I don't know why they are pointed to U://, it looks like a group policy of the Government). U is a network mapped drive and D drive is a local disk. I don't think any network drive would be involved. In particularlly, I always load only one MVBA file to edit, because I would not know what would the behavior to be when you click "Save" Button.

Robert Hook said:

Setting the MicroStation Configuration Variable MS_VBA_OPEN_IN_MEMORY=ALL

That is an interesting suggestion. I will update you the information if I meet the crash again.

If you enable this Configuration Variable, you cannot "Save" the code after editing. If you close the Microstation, it will ask you to save as a new MVBA file. However, the size of new file is 38% of original size. Should I use replace "ALL" by "READONLY"?

Hi clever_anthony ,

clever_anthony said:

Should I use replace "ALL" by "READONLY"?

Depends if (at the time) you need to be acting as a User (Value set to ALL multi-share in production) or as a Developer (Value set to READONLY needing to update R/W the original .mvba file).

HTH,
Bob