CONNECT crashes when I use ifstream

Please follow the MicroStation Programming forum best practices.

Identify Your Platform

Please identify the version of MicroStation, or other product such as PowerDraft, that you are using: MicroStation CONNECT or MicroStation V8i. What is the 8-digit version number (e.g. 10.xx.yy.zz) of MicroStation?

Identify Your Operating System

Please identify the version of Windows you are using.

Build Tools

Are you using Visual Studio or Bentley Make (bmake) to build your project? What version of Visual Studio are you using?

Code Syntax Highlighting

When you post code, use the Forum advanced editor's syntax highlighting tool. That's the icon that resembles a pencil: 

I was running OpenRoad Designer Connect Edition - Version 10.00.00.120

On a Window 10 Pro Workstation Laptop with 16G ram and Core I7-6820HQ CPU

The code sample submitted was using Bentley Make. But similar problem encountered when using Visual Stdio 2012 directly.

I hijacked TagExample code to show the problem. As soon as the following code is called CONNECT crashes at std::getline.

Public void tagsExample_createTagSet (WCharCP unparsed)
{
  std::ifstream inFile;
  inFile.open("C:\\Users\\Public\\test.txt", std::ios_base::in);
  if (inFile.is_open())
  {
    std::string doc;
    std::getline(inFile, doc);
    inFile.close();
  }
}

I was running in Visual Studio Debugger which showed following code as last crash function

virtual int_type __CLR_OR_THIS_CALL uflow()
{ // get an element from stream, point past it
  if (_Mysb::gptr() != 0
    && _Mysb::gptr() < _Mysb::egptr())
    return (_Traits::to_int_type(
        *_Mysb::_Gninc())); // return buffered
  else if (_Myfile == 0)
    return (_Traits::eof()); // no open C stream, fail
  _Reset_back(); // revert from _Mychar buffer
  if (_Pcvt == 0)
  { // no codecvt facet, just get it
    _Elem _Ch = 0;
    return (_Fgetc(_Ch, _Myfile) ? _Traits::to_int_type(_Ch)
      : _Traits::eof());
  }

The code _Fetc was crashing.

Hi Greg,

Unknown said:

when using Visual Stdio 2012 directly

Because the current version of OpenRoads Designer was released before MicroStation CONNECT Edition Update 5, I suppose ORD is based on some earlier MicroStation platform version (I have not ORD installed to be able to check it).

For the development, you have to use Visual Studio 2013 Professional (I guess Community Edition is also acceptable altough not supported officialy), not older (2012) or newer (2015, 2017) versions. When you work with C++, you cannot use "some version", but only the defined version of Microsoft C/C++ compiler. Otherwise there is a threat of weird runtime errors because of MSVCR (C runtime) incompatibilities.

I am not sure if the discussed error is caused by such incompatibility, but in my opinion you have to ensure your code is compiled correctly and to continue the discussion if the error will persist.

WIth regards,

  Jan

Jan,

Thank you for the reply! I had typo in my earlier post. I was indeed using Visual Studio 2013.

You answer explains why we see discrepancy between OpenRoad Designer and Microstation Connect. At the moment, we appear to be able to avoid the problem by using Microsoft File API directly just not fstream. We will keep watching the problem.

Thanks,
-Greg

Hi Greg,

Unknown said:

You answer explains why we see discrepancy between OpenRoad Designer and Microstation Connect.

I agree it can be a bit confusing, because depending on a target platfomr, different VS versions (C++ compilers) have to be used:

• MicroStation CE (from the original release to Update 4) and OpenRoads Designer (current version): Visual Studio 2013
• MicroStation CE Update 5: Visual Studio 2015

Because applications like OpenRoads Designer or AECOsim Building Deisgner are built on top MicroStation platform, I guess the next ORD version will also require Visual Studio 2015, so the ddevelopment will become simpler.

Unknown said:

we appear to be able to avoid the problem by using Microsoft File API directly just not fstream.

Because it seems to be a problem of standard C++ library and not MicroStation Did you try to isolate the code and compile it as independent Visual Studio C++ project?

With regards,

  Jan

Hi Jan,

I'm working with Greg on this issue. The code in question works on MicroStation V8i and Connect Update 3 (compiled with their respective Visual Studio versions). It is crashing in OpenRoads Desinger, AECOsim and Connect Update 5.

It's been in production for us for a while and we are quite confident that it is not a coding problem.

We haven't tried compiling our connect version on VS2015 yet, but we will try that out. I'll let you know the results.

Hi Jan,

So after compiling the code in Visual Studio 2015, the ofstream/ifstream does not crash on Connect Update 5, OpenRoads Designer or AECOsim. However, it does crash on Connect Update 3.

Can you recommend a way that we can programmatically detect in setup what Visual Studio Platform is needed to run on MicroStation Connect?

If there is a way that we can determine through MDL that would also be usful for us to inform the user if they've loaded the wrong file.

We considered trying to force all users to update to the latest Connect release, but in practice that is not going to always be possible.

Thank you,
Chris

Hi Christian,

Unknown said:

Can you recommend a way that we can programmatically detect in setup what Visual Studio Platform is needed to run on MicroStation Connect?

Similar topic was discussed here and in my opinion to use the registry, as discussed, is the right way to go.

Unknown said:

If there is a way that we can determine through MDL that would also be usful for us to inform the user if they've loaded the wrong file.

I am not sure if I understand it correctly. To allow to load wrong dll (e.g. dll compiled for Update 4 using VS 2013 to MicroStation CE Update 5) is the problem of wrong installation / setup and not the application itself. It's not ensured that such dll will work correctly in "not target environment", so even there will be some test implemented, maybe it will fail.

But at the same time I agree it's often better to be more careful and to implement more tests. If you want to check wrong dll was loaded, probably the first task in MDL main method should be to use mdlVersion_getVersionNumberts.

Unknown said:

We considered trying to force all users to update to the latest Connect release, but in practice that is not going to always be possible.

That's something to be always negotiated and it's about a balance between technical issues and the application maintenance cost and sales objectives. I discussed the same question with some my customers and in some cases it will be simpler to focus to new versions only, in others to maintain both VS2013 and VS2015 platforms.

With regards,

  Jan

Unknown said:

After compiling the code in Visual Studio 2015, the ofstream/ifstream does not crash on Connect Update 5, OpenRoads Designer or AECOsim. However, it does crash on Connect Update 3

Viz Studio 2015 tools build a binary for MicroStation 10.05 that is incompatible with an earlier version of MicroStation CONNECT.

Viz Studio 2013 tools build a binary for MicroStation 10.04 and earlier that is incompatible with a later version of MicroStation.

It's the C++ compiler and linker that lay out binary structures in your DLLs.  It's the different, Viz Studio dependent, binary structures that create the incompatibility. 

Configuration File Processing

You have to devise a Windows environment that lets you segregate the DLLs into, say, MS_MDLAPPS_10_04 and MS_MDLAPPS_10_05.  Then append that path to MS_MDLAPPS using some configuration file logic that works out which version of MicroStation is starting up...

MS_MDLAPPS_10_05 = //DevServer/CONNECT/bin/10_05/ # Put your Viz Studio 2015 DLLs here
MS_MDLAPPS_10_04 = //DevServer/CONNECT/bin/10_04/ # Put your Viz Studio 2013 DLLs here

# pseudo-code
%if (MicroStationVersion10.05) then
  MS_MDLAPPS > MS_MDLAPPS_10_05
%endif
%if (MicroStationVersion10.04) then
  MS_MDLAPPS > MS_MDLAPPS_10_04
%endif

_VERSION_x_xx configuration variable

# _VERSION_x_xx   The _VERSION followed by the current major and minor version, defined but has no value.

Unfortunately that information is incorrect.  I'm running CONNECT 10.05, and the only _VERSION variable I can see is _VERSION_10_0.  That is, the minor version number is not included.

I'm open to suggestions from Bentley Systems about a solution to that question.  How do we determine the MicroStation version using configuration file logic?  We need to be able to find both the major and the minor version.

Hi Jan,

Thanks for all your help so far.

Just to address this note from your last reply:

"I am not sure if I understand it correctly. To allow to load wrong dll (e.g. dll compiled for Update 4 using VS 2013 to MicroStation CE Update 5) is the problem of wrong installation / setup and not the application itself. It's not ensured that such dll will work correctly in "not target environment", so even there will be some test implemented, maybe it will fail."


Consider our scenario:

- User has Connect Update 3 installed
- They install our product - everything works great
- They download Connect Update 5 installer, it replaces Update 3 with Update 5.
- Now the user is getting crashes all over the place because the Platform Toolset doesn't match.

In that regard I don't think it's a setup/installation problem. Because of the way this change is rolled out, we don't get a clean way to handle it.

In my opinion, when the platform toolset changes, some versioning should be done in the MA file to prevent Update 3 ma's from being Loaded on Update 5. Similar to if a user tries to load a MicroStation V8i ma into Connect and it won't work.


The 'kludge' i'm considering to protect our users is to detect the MicroStation version on startup, and if the DLL that happens to be loaded is the incorrect one. We can notify the users to correct their installation and unload gracefully. - It could be unsafe, but in practice as long as we use standard windows calls with no shared memory use, then mixing Dlls with a different compiler should work.

I'm going to investigate Jon's suggestions below further which also could be a viable solution.


Thanks again for your prompt help on this issue.

Warm Regards,
Chris