MicroStation CONNECT 10.17.00.209
I have a VBA from a client that is locked, it runs a startup macro and throws a file not found error every time a DGN file is opened. Is there a logging system I can turn on to find out WHICH file it's trying to find so I can fix it? VBA is locked from viewing.
Hi Kevin van Haaren,
Glad to hear that helped to resolve your issue.
For cases of "Files not found" the path I find most effective is to "Create a Filter" (e.g. MicroStationFilesNotFound) and Save/Share wither others as a *.pmf file; to readily load the "next time" of need; consisting something like below as a starting point:
HTH,Bob
Process Monitor was the way I went. I used Procmon64.exe and if you want usable info from Procmon it's important to narrow down the amount of monitoring you do via the Filters.
Rather than monitoring an entire "open a file and wait for the error to happen" cycle I first I figured out which vba was causing the problem. It was an autoload one so I just brought up the list of VBA's with key-in vba run then manually ran each of the OnProjectLoad macros to figure out which it was.
Now I could trigger the problem on demand. I started up procmon and added a filter:
Process Name is not OpenRoadsDesigner.exe => Exclude
I also turned off network and registry monitoring since I figured they weren't the cause.
I started the monitor, triggered the error, stopped monitoring. Still had tons of events, but I could see there was frequently a result "NAME NOT FOUND" so I added a filter to exclude all other result messages.
Ah, now I can see it among the other name not found errors (usually dll.config files), one more filter to see all the paths it was checking for that file. That let me figure out which config variable it was using to look for the file, and that led me to find the error in my config file that was excluding the one directory the file was in.
Thanks for the reminder about procmon.
Kevin van Haaren said:VBA is like a 20 year old technology
VBA is a development of Visual Basic 5, and contains elements of VB6 introduced in 1998.
Kevin van Haaren said:the password is more of annoyanc
Yes, and that's why nobody creates commercial apps using VB/VBA.
There was a time when many Microsoft products had feeble security. For example, you could use an SQL database simply by entering for the user password a sequence of digits divisible by 7.
Regards, Jon Summers LA Solutions
It depends how long you want to spend on getting the information you need. Bob's suggestion isn't something I've ever used so I can't speak from experience on what result it gives you. I have done what I suggested and it worked without issue.
You know, I'm so used to modern password protection using AES and other (currently) unbreakable methods I totally forgot VBA is like a 20 year old technology and the password is more of annoyance than an actual impediment.
I'll save this as a last resort though :)
Ah thanks, I'll give that a go.
If you are in need or trying to identify What Files (Registry, Network, or public Call Stacks) are being accessed, the results of each and in Sequential order, I suggest learning, using and applying Microsoft Process Monitor to help provide background troubleshooting details and empirically inform you of what (any) applications are doing at a point in time and the order/locations performed (by design).
Granted the immediate results can be overwhelming so try to limit the capture (time) to the individual workflow/action in question then Search and check out a few YouTube videos like (Search: Create Effective Promon Filters) this one.
No matter what, you will likely find the information you need by capturing and filtering a Microsoft Process Monitor log around the event of interest.
Answer Verified By: Kevin van Haaren
If it was me, I’d make a copy of the MVBA file and remove the password using a Hex editor. Then the source code is available to view to find out what file is raising the error.