Exception thrown at 0x79C8F860 (sfml-system-d-2.dll)

Started by rbenn674, 08 December 2022, 23:05:56


When using Cmake to compile and run a debug version of gui-builder I receive the following error:

Exception thrown at 0x79C8F860 (sfml-system-d-2.dll) in gui-builder.exe: 0xC0000005: Access violation reading location 0x00000027.

I have tried compiling as a static exe but I always seem to get a load of LNK issues. I have successfully compiled and run the release version with no issues.

Screenshot 2022-12-08 170346.png


Did you build TGUI or SFML yourself or did you download them from the website?
I think this error might be possible when using a different SFML dll than was used to build TGUI with.

Did you build the debug TGUI libs to a different build folder than where you build the release TGUI libs?

If you link statically then there are 2 things to do that would give you many linker errors if you didn't (most people forget the second one):
- Add opengl32.lib, freetype.lib, winmm.lib and gdi32.lib to the linker libraries (where you added SFML .lib files). Those are SFML dependencies which you need to link to when linking statically.


I am using a pre-compiled version of SFML 2.5.1.

Yes they are in two different folders:


Looking into the debug library I see tgui-d.lib & pdb, and tgui-s-d.lib & tgui-s-d.lib are inside.

Yes, Define Static was performed. I actually have tried many combinations of options in CMAKE to try to make the build work without issues.

gdi32.lib was not in the SFML folder and never has been. The other two are in there.

I redownloaded the "Visual C++ 15 (2017) - 32-bit" and verified gdi32.lib does not exist.

The strange thing is, I have a separate repos directory that does work in debug mode, and in static, although I had to change settings in cmake quite a bit to get that to work, and in that build I cannot get the dynamic linking to work.

Also, what is difference between the "gui-builder.exe (install)" and "gui-builder.exe" ?


Only freetype.lib is included with SFML, gdi32.lib, winmm.lib and opengl.lib (not openal.lib) are part of Windows. You only have to add those to the linker settings, you don't have to copy them anywhere.

Are you using CMake for your project? Because I was assuming that you were using Visual Studio directly. The procedure to link SFML and TGUI is different in CMake. If you are using cmake for your project, can you show how you are searching and linking to SFML and TGUI?

Since you are using precompiled libraries for SFML, is there a specific reason why you aren't using precompiled libraries for TGUI?

QuoteAlso, what is difference between the "gui-builder.exe (install)" and "gui-builder.exe" ?
Where do you see those? I'm not sure what you are referring too.


I am using Cmake inside of Visual Studio. I am building the gui-builder.exe itself with rewritten source code, so I assumed CMake was required to do this.

I am using the pre compiled for my project (for which I have no issues), but in modifying the gui-builder I am using github pulls and Cmake.

I checked my cmake for the working debug repository and it is exactly the same. So strange.

There is two options to build in my cmake for "install" or "build":


JSon for cmake:

  "configurations": [
      "name": "x86-Debug",
      "generator": "Ninja",
      "configurationType": "Debug",
      "inheritEnvironments": [ "msvc_x86_x64" ],
      "buildRoot": "${projectDir}\\out\\build\\${name}",
      "installRoot": "${projectDir}\\out\\install\\${name}",
      "cmakeCommandArgs": "",
      "buildCommandArgs": "",
      "ctestCommandArgs": "",
      "variables": [
          "name": "SFML_DIR",
          "value": "C:/Users/rbenn/Documents/Visual Studio 2019/SimpleGui/SimpleGui/SFML-2.5.1/lib/cmake/SFML",
          "type": "PATH"
          "name": "TGUI_USE_STATIC_STD_LIBS",
          "value": "False",
          "type": "BOOL"
          "name": "TGUI_SHARED_LIBS",
          "value": "False",
          "type": "BOOL"
          "name": "CMAKE_MAKE_PROGRAM",
          "value": "C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe",
          "type": "FILEPATH"


I can't help with that, because I've never done anything similar.
The one with "(install)" will likely run the install instructions from CMake which you probably don't need to do (but it will likely run all the stuff from the non-install target first, so there wouldn't be much of a difference between the two targets).

I rarely touch the gui builder on Windows, and the way I develop it on Linux isn't usable for you, but what I usually do on Windows is to just run CMake in the TGUI root folder. Not via Visual Studio, but by just using the CMake GUI and setting the source directory to the TGUI root (and a build folder to a new directory). As generator I select Visual Studio. After pressing configure, setting the correct values (e.g. SFML_DIR), pressing configure and generate, you can open the project created in the build directory (from CMake with the "Open Project" button).
This gives you a VS project that builds TGUI and the Gui Builder. In the Solution Explorer on the left side in VS you can set the gui-builder project to be the active project so that you can run it.

Unfortunately, because I never optimized for developing on Windows, the gui-builder target isn't actually designed to run this way out of the box. If you link dynamically it will complain about dll files, you have to copy them next to the gui-builder.exe file that gets created in some subdirectory of your build folder. Even when the gui builder launches, it will immediately terminate. This is because it can't find its resources. You have to also copy the "resources" and "themes" directories, that you find in the gui-builder directory (in TGUI root), next to the gui-builder.exe file. After that you should be able to correctly run the program from inside VS.

Edit: I'll have a look at your PR tomorrow btw.


Well I did as you mentioned and built the program using the pre-compiled files with the root file Cmake... It works perfectly the first attempt (after including the resource folder etc. so it doesn't close immediately).

I then deleted my repository gui-builder folder contents, re-ran the cmake and tossed all the same .dll files + resource folder .etc from the precompiled build and everything works now. Not sure why it wasn't working before, either a glitch with cMake or one of my .dll files was incorrect like tgui-d.dll ?
Anyways, thanks for the help...


Quoteone of my .dll files was incorrect like tgui-d.dll ?
That's the only thing that I can think of, some dll file which didn't exactly match. It's good that it is fixed now.