Working with our consultants, we have seen a number of issues where our workspace is not correctly configured and a launch of MicroStation dies at a particular line in the process. We have always concentrated on getting the assignments that we supply corrected, which fixes the problem. But today, an internal user was experiencing the same problem. In this case, a number of file in ProjectWise were configured to load a particular workspace profile. This, is not a ProjectWise issue however. At its core, it is an obsolete default assignment in msconfig.cfg. This particular profile tried to use a startup.cfg file. However, the location the file used to reside at does not exist anymore. So, when a startup.cfg is specified in error, MicroStation loads msconfig and processes whatever the default settings are. This is where the problem occurs.
Lines 68 and 69, define _USTN_BENTLEYROOT and _USTN_WORKSPACEROOT. However, _USTN_WORKSPACEROOT is defined as a Workspace subfolder under _USTN_BENTLEYROOT. At some point, the default workspace was moved from the Program Files (x86) folder structure to the ALLUSERSPROFILE location.
By not setting this path correctly, MicroStation cannot start if it is mising its startup.cfg file, be that mslocal.cfg or a special startup.cfg called by a command line switch.
This error can be traced back to the fact that when msconfig.cfg is loaded without msdir.cfg, the variable _USTN_WORKSPACEROOT does not get assigned so the assignemt in msconfig.cfg get used.
A simple fix would be to add a test for its definition and then to attempt assign it using the path in ALLUSERSPROFILE to build a likely location. Even this could be tested before any assignment is made. And if it is unable to locate a local workspace, it should be able to generate an error message.
During the install process there are certain things that get set so MicroStation knows where it is installed. If you choose to move these after the fact then MicroStation can no longer find them. You would encounter the same issue if at some point the program was moved from its originally installed location.
Timothy Hickman
CADD Manager | CADD Department
timothy.hickman@colliersengineering.com
Main: 877 627 3772|
1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691
Nothing of MicroStation was moved. A custom startup.cfg file was originally saved in a shared folder location that has since been removed. When you create a shortcut that attempts to use a startup.cfg file, but that command line switch contains an error, MicroStation still launches and still processes msconfig.cfg and that loads whatever it usually does, but without the benefit of any paths in msdir.cfg.
The net result of this behavior is any attempt to read a workspace file is now pointed at a folder where there is no workspace which eventually fails. It took a trained eye to recognize that the path to the entire workspace was incorrect. IMHO, Bentley should deliver a product that when it has some type of default behavior, still runs, or opens a dialog box explaining why it failed to run. How hard would it be to make a msconfig.cfg that assumes the current default workspace folder location as a fail-safe assignment in the event that msdir.cfg is bypassed?
Charles (Chuck) Rheault CADD Manager
MDOT State Highway Administration Maryland DOT - State Highway Administration User Communities Page
so this is a PW Managed workspace ?
It's a file from before they were doing managed workspaces, so it used a workspace profile. Forgive me for my lack of knowledge but I've only been allowed behind the curtain since early November and am still learning the backside of PW. These seem to operate very differently so I feel like Managed Workspace uses configuration blocks while Workspace Profiles seem to use CFG files and even some local workspace settings.
Also, after responding, I tried a shortcut supplied by our support consultant that had a startup config with an incorrect path. Same error message: A workspace Root file not found in the C:\Program Files (x86) folders and not the C:\ProgramData folders.
Have you run a -debug session to see when the assignment to the correct path to C:\ProgramData occures, because it clearly never happens on my end.
There is a default workspace location suggested during the install process. That seems like an ideal place to point a fail-safe path for the workspace.
are you using PW to select the DGN file and have MS open it ?
Yes
Here is an additional update:
For years, I edited mslocal.cfg to add variables in front of msconfic.cfg, so that some of its assignments were reading cfg files from the network and not the local workspace. I have been pounded on by Bentley and other users (CADD Manager types) that I should never edit mslocal.cfg because of the warning in msconfig about modifying any delivered cfg files.
Thanks to Microsoft, it keeps getting more and more difficult to make those edits. This became an issue at my last company as they went to Cloud PC's and I was no longer able to make these edits. So now, at my current position, we began having problems with installation procedures that also would replace mslocal.cfg. So we tried using my newfound knowledge and experience with waiting until the local workspace Standards.cfg files are read to start assigning and including other network CFG files.
Except today, we tried a fresh install and tried opening a number of files in the un-managed workspace that uses a workspace profile. But it needs a variable defined before msconfig.cfg that points to our workspace internally, but consultants can assign to look at their workspace externally.
If this is not done, then we get the same error - a ucf file that is being looked for at the install folder tree instead of the installed workspace tree, or our workspace, or any workspace.