Error 193 loading custom application

Hi Robert Kock,

MicroStation CONNECT (and respective SDKs) Update 12 thru 16 require Microsoft Visual Studio 2017 (MSVC 14.1) vs. VS2015 (MSVC 14.0). Ref: MicroStation CONNECT SDK Requirements.

Do you notice the issue if re-compiling with the required VS 2017?

It is worth noting in the near future when MicroStation CONNECT Update 16.1 releases Microsoft Visual Studio 2019 (MSVC 14.2) will be the default toolset required.

HTH,
Bob

Hi Robert,

Thanks for your reply. I'll check it out and be back to you.

The question is: how come everyting does work on the PC on which I compiled everything? 

Robert Kock said:

I got various versions of Windows SDK on my PC. Can I simply uninstall them after having uninstalled VS 2019? Does the installation of VS 2017 include the correct version of Windows SDK?

Those are questions for a Microsoft support site.  We're happy to advise about MicroStation development on this Forum, and there are many more people on other Forums who like to discuss Viz Studio and the Windows SDK.

Hi Robert,

Robert Kock said:

When creating my development environment, I simply installed the latest version of VS.

honestly, I do not understand the logic. When I want to develop anything in any language, using any tool, the first thing is to check and follow prerequisites exactly (regardless it's MicroStation using C++ or iTwin.js using TypeScript). It's never like "just to install the latest version", even in a case of such flexible environment like NET ... and especially not in the case of C/C++, famous because of problems with MSVCRT versions and "dll hell".

Robert Kock said:

I'll try to uninstall VS2019 and install VS2017.

There is no reason to uninstall VS2019, when used for another projects. I typically have 2 or 3 versions installed in parallel, of course not as full installations (because it does not makes sense and consumes too much space), but in configurations containing what I need for active projects.

Because I use VS2019 for all NET development, I typically use it as editor for C++ code also. When such code is compiled using bmake, VS2017 (C++ compiler/linker) is used automatically, so no compatibility problem exists.

Robert Kock said:

MS CE Update 16 was installed when the Connection Client suggested me to do so.

It's automatic, no exceptions: When new MicroStation version is installed and you want to develop application for such version, you have to reinstall SDK also.

When new MicroStation or MicroStation SDK is released, it's announced in MicroStation Announcements forum, so there is no obstacle to be informed when a pair Microstation + SDK is available.

Robert Kock said:

I'll start from scratch and see what happens.

When new MicroStation SDK is installed, it's always recommended to try to compile (all) delivered examples and to test some, to test everything is installed and set correctly.

Robert Kock said:

I got various versions of Windows SDK on my PC. Can I simply uninstall them after having uninstalled VS 2019?

It's up to you, whether you need them or not.

Robert Kock said:

Does the installation of VS 2017 include the correct version of Windows SDK?

I am not sure what do you mean by "correct version of Windows SDK". "Correct" for what? If you mean "for MicroStation", I recommend to check SDK release announcement, where required VS parts are mentioned, Also, what is necessary from Visual Studio installation was discussed several times in this forum, so use search.

When you need any specific version of Windows SDK for other project than MicroStation, it makes sense to install it independently from Microsoft archive, because Windows SDK is independent completely. Visual Studio should be able to recognize the installation automatically (even when maybe does not work when the latest SDK and old VS combination is used).

Regards,

  Jan

I'm mainly a Java programmer in a Unix environment and not used to the strict dependencies of Windows and/or C++.

You're never too old to learn

Robert Kock said:

I'm mainly a Java programmer

In such context, to use C# would be "more friendly way" because of many similarities with Java. But, in MicroStation, NET API is a bit more limited than C++ (but no so much), on the other hand it offers WPF GUI, rich environment and one from the best dev tools available.

Robert Kock said:

in a Unix environment and not used to the strict dependencies of Windows and/or C++.

Yes,that's often discussed question why Microsoft did not use some concept from shared libraries and other ideas, known at the time, when dlls were invented.

Fortunately, because C++ has been back in a main Microsoft focus for last few years, and is developed actively now (including ISO standardization), new MS C++ compilers and MSVCRTs solve the compatibility problem partially. Technically it's possible now to use VS2019 to compile native dll exactly as it was in VS2017, maintaining compatibility, but it requires good knowledge how the system works.

But in the case of MicroStation, when you do not want to invest time into own research and creating own environment, leading to maybe correct and compatible result, but still not supported officially, it's simpler to use standard supported tools (including bmake, which a lot of people do not like, but that does a lot of tasks and settings automatically).

Robert Kock said:

You're never too old to learn

Tell me about it :-) My recent trip from "always desktop" to "web systems" and learning things like Node.js, JavaScirpt, TypeScript and some popular frameworks is just challenging :-))))

Regards,

  Jan

OK, I uninstalled VS 2019 and installed VS 2017. Made the necessary changes in the *.vcxproj file and recompiled everything.

Made sure that the various installations on the source and target machines are perfectly aligned.

Unfortunately, I get the very same result: error 193 when loading my application.

I got 1 very serious doubt: on my target machine I have also MicroStation V8i SS10 installed (for legacy reasons; we're still porting everything). Could that influence the behaviour?

Thanks again,

Robert

Robert Kock said:

on my target machine I have also MicroStation V8i SS10 installed (for legacy reasons; we're still porting everything). Could that influence the behaviour?

MicroStation CONNECT is a 64-bit app., MicroStation V8i is a 32-bit app.  Bentley Systems tells that it is OK to have both versions installed on the same computer.  The app. Registry data lives in separate parts of the Windows Registry.

Do you have any Windows environment variables set that could confuse things?  For example, does MS (if you have it defined) point to the CONNECT version of MicroStation?

My development computer has had both versions installed with no problems, and I'm sure that others can confirm that.

Robert Kock said:

at startup it gives me error 193 (the OS could not load myappl.dll)

Where have you put your app. (which folder) on the other computer?  What version of MicroStation CONNECT (or other product) is installed on that computer?

Hi Robert,

Robert Kock said:

Unfortunately, I get the very same result: error 193 when loading my application.

I agree with Jon that to check Windows and MicroStation configuration makes sense, but to know the application code may help too:

In .ma source code (.r), how DllMdlApp structure is defined? It points to .dll file that should be loaded. Is it possible that it points to another dll (another name) file? Or, as Jon mentioned, configuration variables are set in such way, that another (e.g. some older) version is loaded (even though I assume the file from the same folder should be loaded first).

Also, because, as you mentioned, error 193 is typically mentioned in relation to 32 / 64bit dll mismatch, is it possible there is also 32bit version of the same dll available?

With regards,

  Jan

Hi Jan/Jon,

First of all, thank you so much for your effort. Though the problem is still not resolved, you're doing everything to help me.

My target machine:

Windows 10 Pro, version 21H1, build 19043.1165

Processor AMD Ryzen 5 5600U, 2.30GHz

16GB RAM

Microstation Connect Edition, version 10.16.0.80

I got the variable $MS point to CE and not to V8i.

The script that launches MS contains the line:

start %MS%microstation.exe -wdoracle -wusigra-it %SIGRA%\data\logosigra.dgn

The %SIGRA% points to the root directory of all my files, including all custom .ma and .dll

The logo-DGN is opened correctly at startup

When I rename the dll, putting an underscore in front, I get error "Cannot find myappl.dll" (or something similar, I got the Italian version). So, MS is trying to load the correct dll.

I double checked by means of the VS utility DUMPBIN and the DLL is actually 64 bit.

In myappl.r, I defined:

#define DLLAPP_MYAPPL 1

DllMdlApp DLLAPP_MYAPPL =
{
  L"myappl", L"myappl"
}

I searched the whole harddisk of the target machine and there's no other file with the same name.

My development machine:

Windows 10 Pro, version 20H2, build 19042.1165

Processor Intel Core i7-10510U, 2.30GHz

16GB RAM

Microstation Connect Edition, version 10.16.0.80

Personally, I don't think that the Windows build and/or type of processor make any difference.

I'm quite sure I made a very stupid error or have overseen something very obvious.....

Robert Kock said:

The %SIGRA% points to the root directory of all my files, including all custom .ma and .dll

What is the definition of MicroStation configuration variable MS_MDLAPPS?

In the user's configuration file, we got, among others, the following entries:

• MS_SETTINGSDIR = $(SIGRA)/data
• MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano
• MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano
• MS_MDL < $(SIGRA)/so_nt/apps/italiano
• MS_DGNAPPS = myappl

Where %SIGRA% equals C:\SirenCE

My CE custom applications are found in C:\SirenCE\so_nt\apps\italiano

It seems everything is pointing to the correct directories

In the user's configuration file, we got, among others, the following entries:

• MS_SETTINGSDIR = $(SIGRA)/data
• MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano
• MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano
• MS_MDL < $(SIGRA)/so_nt/apps/italiano
• MS_DGNAPPS = myappl

Where %SIGRA% equals C:\SirenCE

My CE custom applications are found in C:\SirenCE\so_nt\apps\italiano

It seems everything is pointing to the correct directories

Robert Kock said:

• MS_SETTINGSDIR = $(SIGRA)/data
• MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano
• MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano
• MS_MDL < $(SIGRA)/so_nt/apps/italiano

If those are defined in a configuration file, then you must append a slash (/) to each folder path.  Without the trailing slash, MicroStation tries to interpret the value as a file specification.

MS_SETTINGSDIR = $(SIGRA)/data/
MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano/
MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano/
MS_MDL < $(SIGRA)/so_nt/apps/italiano/

Or, easier to maintain...

SIGRA_ITALIANO = $(SIGRA)/so_nt/apps/italiano/
SIGRA_INGLESE = $(SIGRA)/so_nt/apps/english/
SIGRA_LANGUAGE = $(SIGRA_ITALIANO)
MS_MDLAPPS < $(SIGRA_LANGUAGE)
MS_LIBRARY_PATH < $(SIGRA_LANGUAGE)
MS_MDL < $(SIGRA_LANGUAGE)

Hi Jon,

In my previous reply I made an error during copy/paste: within the configuration file all directory entries already have a trailing slash.

By the way, within the reply I manually resolved some environment variables.

The real entry is:

MD_MDLAPPS < $(SIGRA)/$(SISTEMA)/apps/$(LINGUAGGIO)/

Where:

$(SISTEMA) equals "so_nt" and

$(LINGUAGGIO) equals "italiano"

Robert Kock said:

Where %SIGRA% equals C:\SirenCE

Given that %SIGRA% should instead equal C:/SirenCE/

Jon Summers said:

Or, easier to maintain...

SIGRA_ITALIANO = $(SIGRA)/so_nt/apps/italiano/
SIGRA_INGLESE = $(SIGRA)/so_nt/apps/english/
SIGRA_LANGUAGE = $(SIGRA_ITALIANO)
MS_MDLAPPS < $(SIGRA_LANGUAGE)
MS_LIBRARY_PATH < $(SIGRA_LANGUAGE)
MS_MDL < $(SIGRA_LANGUAGE)

Your suggestions ought to be written as:

SIGRA_ITALIANO = $(SIGRA)so_nt/apps/italiano/
SIGRA_INGLESE = $(SIGRA)so_nt/apps/english/
SIGRA_LANGUAGE = $(SIGRA_ITALIANO)
MS_MDLAPPS < $(SIGRA_LANGUAGE)
MS_LIBRARY_PATH < $(SIGRA_LANGUAGE)
MS_MDL < $(SIGRA_LANGUAGE)

Barry Lothian said:

Given that %SIGRA% should instead equal C:/SirenCE/

We don't know.  There may be other reasons why SIGRA — a Windows environment variable — should not have a trailing slash.  The rules of MicroStation configuration variable definition should not be applied to Windows environment variables without testing.

Barry Lothian said:

Your suggestions ought to be written

I don't know about ought.  They could be written without a slash after $(SIGRA) if that were to be redefined as you advise.

Robert Kock said:

I made an error during copy/paste: within the configuration file all directory entries already have a trailing slash

So this discussion is moot.

I'm not sure if it may help, but I hereby attach the output of DUMPBIN /HEADERS /DEPENDENTS of the DLL.

So far, I've always referred to the DLL as "myappl" while its actual name is "SHD_LIBRARY". It is loaded at startup and exports tons of functions used by other customer applications.

Its MdlMain, after some general initialization, launches a second application that executes the login procedure.

Microsoft (R) COFF/PE Dumper Version 14.16.27045.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file C:\Develop\SIREN-INP\CAD_CE\rilascio\SIGRA-IT\so_nt\wind\apps\italiano\shd_library.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
            8664 machine (x64)
               6 number of sections
        61250C25 time date stamp Tue Aug 24 17:11:33 2021
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
            2022 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   DLL

OPTIONAL HEADER VALUES
             20B magic # (PE32+)
           14.16 linker version
          1C1000 size of code
         43FFA00 size of initialized data
               0 size of uninitialized data
          1BB67C entry point (00000001801BB67C) _DllMainCRTStartup
            1000 base of code
       180000000 image base (0000000180000000 to 00000001845C4FFF)
            1000 section alignment
             200 file alignment
            6.00 operating system version
            0.00 image version
            6.00 subsystem version
               0 Win32 version
         45C5000 size of image
             400 size of headers
               0 checksum
               2 subsystem (Windows GUI)
             160 DLL characteristics
                   High Entropy Virtual Addresses
                   Dynamic base
                   NX compatible
          100000 size of stack reserve
            1000 size of stack commit
          100000 size of heap reserve
            1000 size of heap commit
               0 loader flags
              10 number of directories
          244830 [    5FA4] RVA [size] of Export Directory
          24A7D4 [     190] RVA [size] of Import Directory
         45C3000 [      F8] RVA [size] of Resource Directory
         45B7000 [    B1E4] RVA [size] of Exception Directory
               0 [       0] RVA [size] of Certificates Directory
         45C4000 [     7B0] RVA [size] of Base Relocation Directory
          22A770 [      70] RVA [size] of Debug Directory
               0 [       0] RVA [size] of Architecture Directory
               0 [       0] RVA [size] of Global Pointer Directory
          22A8E0 [      28] RVA [size] of Thread Storage Directory
          22A7E0 [     100] RVA [size] of Load Configuration Directory
               0 [       0] RVA [size] of Bound Import Directory
          1C2000 [    1360] RVA [size] of Import Address Table Directory
               0 [       0] RVA [size] of Delay Import Directory
               0 [       0] RVA [size] of COM Descriptor Directory
               0 [       0] RVA [size] of Reserved Directory


SECTION HEADER #1
   .text name
  1C0F0D virtual size
    1000 virtual address (0000000180001000 to 00000001801C1F0C)
  1C1000 size of raw data
     400 file pointer to raw data (00000400 to 001C13FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
60000020 flags
         Code
         Execute Read

SECTION HEADER #2
  .rdata name
   8E02C virtual size
  1C2000 virtual address (00000001801C2000 to 000000018025002B)
   8E200 size of raw data
  1C1400 file pointer to raw data (001C1400 to 0024F5FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         Read Only

  Debug Directories

        Time Type        Size      RVA  Pointer
    -------- ------- -------- -------- --------
    61250C25 cv            6F 0022C3BC   22B7BC    Format: RSDS, {E84A2B0D-BB33-4FC4-B598-252FFC915B9B}, 1, C:\Develop\SIREN-INP\cad_ce\rilascio\SIGRA-IT\so_nt\wind\apps\italiano\shd_library.pdb
    61250C25 feat          14 0022C42C   22B82C    Counts: Pre-VC++ 11.00=0, C/C++=118, /GS=118, /sdl=85, guardN=33
    61250C25 coffgrp      338 0022C440   22B840    4C544347 (LTCG)
    61250C25 iltcg          0 00000000        0

  Image has the following dependencies:

    KERNEL32.dll
    USER32.dll
    OCI.dll
    USTATION.dll
    Bentley5.dll
    BentleyAllocator.dll
    DgnPlatform5.dll
    RmgrTools3.dll
    BentleyGeom5.dll
    MSVCP140.dll
    VCRUNTIME140.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll

SECTION HEADER #3
   .data name
 4365B38 virtual size
  251000 virtual address (0000000180251000 to 00000001845B6B37)
    2800 size of raw data
  24F600 file pointer to raw data (0024F600 to 00251DFF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0000040 flags
         Initialized Data
         Read Write

SECTION HEADER #4
  .pdata name
    B1E4 virtual size
 45B7000 virtual address (00000001845B7000 to 00000001845C21E3)
    B200 size of raw data
  251E00 file pointer to raw data (00251E00 to 0025CFFF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         Read Only

SECTION HEADER #5
   .rsrc name
      F8 virtual size
 45C3000 virtual address (00000001845C3000 to 00000001845C30F7)
     200 size of raw data
  25D000 file pointer to raw data (0025D000 to 0025D1FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40000040 flags
         Initialized Data
         Read Only

SECTION HEADER #6
  .reloc name
     7B0 virtual size
 45C4000 virtual address (00000001845C4000 to 00000001845C47AF)
     800 size of raw data
  25D200 file pointer to raw data (0025D200 to 0025D9FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
42000040 flags
         Initialized Data
         Discardable
         Read Only

  Summary

     4366000 .data
        C000 .pdata
       8F000 .rdata
        1000 .reloc
        1000 .rsrc
      1C1000 .text

Robert Kock said:

Image has the following dependencies

Are those DLLs all present on the non-working computer? 

I hardly dare to admit, but I forgot to install the 64bit version of the oracle client.

Things are workly correctly now.

Thank you so much and sorry I wasted your time.

You wrote it: It will be something very simple (and obvious) :-)))))))