gdbus.exe has stopped working - error message after closing a Cherrytree file in version 1.2.0

[Atlntssplayer]

Version, Operating system Cherrytree version 1.2.0 (both nolatex and normal portable releases) Windows 7 x64

Describe the bug Using Cherrytree version 1.2.0 after closing a .ctd file I get the error message from Windows that "gdbus.exe has stopped working". This happens even after just opening and closing a Cherrytree document without modifying anything in it. Happens with the nolatex and normal versions too. I only tested the portable releases, cherrytree_1.2.0.0_win64_portable.7z and cherrytree_1.2.0.0_win64_portable_nolatex.7z. I also tested the following older versions for this bug and it didn't happen: 1.1.4, 1.1.3, 1.1.2, 0.39.4 I tested with 2 different documents, a smaller one with about 20 nodes and a big one with about 1900 nodes and the bug happened with both.

To Reproduce If applicable, attach a non-personal document where the issue can be reproduced systematically. Steps to reproduce the behavior:

1. Open .ctd file with Cherrytree version 1.2.0
2. Close Cherrytree
3. gdbus.exe has stopped working error happens.

[giuspen]

Hello @Atlntssplayer and thanks for reporting. I'm not seeing this on Windows 11, I will try later on a Windows 10. gdbus.exe / DBus ( https://en.wikipedia.org/wiki/D-Bus ) is used from cherrytree to communicate between the first and the subsequent instances. Typically every instance (when you open a file or just start from the menu) tries first to talk to an already existing instance to "pass the ball" and exit instead of having many independent instances running. It's not something you should worry too much because the worse that can happen is that you have more than one instance of cherrytree running on the same file independently, but if I can reproduce it I will look at why is doing so. Unfortunately I don't have a Windows 7, I'll see if we can reproduce at least on a Windows 10.

[giuspen]

Also tested on a Windows 10, could not replicate the issue.

[Atlntssplayer]

Thanks for looking into it. If it can't corrupt the opened file than I'm not worried.

I have WinDbg installed and used it before to get a stack trace for devs of another software that was crashing. Maybe I can use it in this case too if you can't reproduce the problem on your end. I would need symbol files for it though. I'm not a dev myself so I don't really know how things work. Anyway if I can help more feel free to tell me what to do. I love Cherrytree. :)

[giuspen]

No worries @Atlntssplayer as it's not dangerous and probably only happening on Windows 7, if you are curious yourself and want to dig this further, you would have to try and build/run from the sources as described in https://github.com/giuspen/cherrytree/blob/master/BUILDING.md#building-cherrytree-on-windows - Take care ;)

[JGKle]

I'm seeing this too, on Windows 10 1809. gdbus.exe crashes shortly after exiting CherryTree 1.2.0 each time.

[JGKle]

Also: I'm using a multi-file db, not ctd

[giuspen]

Thanks for reporting @metal450 are you also using a portable version or you have it installed?

[JGKle]

Installed

[csttsn]

Having the same issue, W11 Pro with all latest updates, portable version, gdbus.exe crashes after closing the Cherrytree (you can view the error description in "Problem Reports" in the Control Panel).

Source gdbus.exe

Summary Stopped working

Date ‎09-‎Oct-‎24 18:25

Status Report sent

Description Faulting Application Path: C:\Utilities\CherryTree\mingw64\bin\gdbus.exe

Problem signature Problem Event Name: APPCRASH Application Name: gdbus.exe Application Version: 0.0.0.0 Application Timestamp: 6700188c Fault Module Name: libglib-2.0-0.dll Fault Module Version: 2.82.1.0 Fault Module Timestamp: 67001889 Exception Code: 40000015 Exception Offset: 00000000000c1085 OS Version: 10.0.22631.2.0.0.256.48

[B-Down]

Same here with W7, portable (w/LaTeX), gdbus error a few seconds after closing CT.

Since I never had that "issue" with previous versions (I used 1.0.4, 1.1.2, 1.1.4, all portable), I did some science of my own, if that can be of any help (either to pinpoint the error, or merely get rid of it)...

I copied the following files from 1.1.4 to 1.2.0:

• gdbus.exe
• gdbus-codegen.exe
• gio.exe
• gio-querymodules.exe
• libgio-2.0-0.dll
• libgiomm-2.4-1.dll
• gdbus-codegen-script.py

There may be more (or even less) files pertaining to gdbus, but copying those over made that error disappear (or, well, not appear 😉). I didn't see any difference with those "new" files, but I didn't test it thoroughly: I went through a number of menus, parameters, opened a couple ctd files... everything seems ok so far.

Edit: Fun fact, I only just noticed csttsn's message mentioning libglib-2.0-0.dll being at fault, but I didn't touch that one... 🤷

Fun fact #2: with my files-wrangling, gdbus.exe doesn't get killed when CT is closed.

[csttsn]

I copied the following files from 1.1.4 to 1.2.0:

Tried replacing only libglib-2.0-0.dll with the version from 1.4, but the program does not start. So I decided to revert back to 1.1.4 for now, which is working flawlessly. I hope giuspen will manage to find the cause of this crash.

[giuspen]

@B-Down if you take only gdbus.exe from 1.1.4 and overwrite it into 1.2.0, is the crash still happening? Your help here is very useful since I cannot see the crash myself, it seems to me clear it's a library/msys2 platform component issue and if you help me to cherry-pick the minimum older component to revert I can then submit here a new bundle so that who has the crash can try it and confirm that it works for them too.

[B-Down]

@B-Down if you take only gdbus.exe from 1.1.4 and overwrite it into 1.2.0, is the crash still happening?

It does, with the very same error.

Tried replacing only libglib-2.0-0.dll with the version from 1.4, but the program does not start

Well, you quoted one line from my message and seemed to have ignored the rest of it (I listed all the files I replaced and specified that I didn't touch libglib), so no wonder you didn't get the same result... 🤷

[csttsn]

Well, you quoted one line from my message and seemed to have ignored the rest of it (I listed all the files I replaced and specified that I didn't touch libglib), so no wonder you didn't get the same result...

I just wanted to test whether replacing this one file will solve the issue, since it is mentioned in the crash log, but looks like it is a part of the larger component that was updated, since, for example, additionally replacing gdbus.exe does not help either. I'm amazed you managed to quickly figure out the full list of files to be replaced to avoid the crash.

[B-Down]

I just wanted to test whether replacing this one file will solve the issue

When you put it that way, it makes perfect sense 👍

As for "figuring out" the files, it was merely a process of elimination: I first tried with only replacing the two "obvious" files (gdbus.exe and gdbus-codegen.exe), but since that didn't end too well (it stil produced the error), I dug a bit more about which files could be about gdbus... As mentioned in my initial message, I probably didn't catch 'em all, and the end result isn't completely satifactory either, with gdbus.exe not existing after CT is closed, so here's hoping @giuspen can figure it out 🤞

[giuspen]

Anybody experiencing this issue after closing cherrytree, could try https://www.giuspen.net/software/cherrytree_1.2.0.0+13_win64_portable.7z and report if it still happens?

[JGKle]

Looks like that fixes it

[B-Down]

CT doesn't launch at all for me (W7) with this version: not a single process appears on the task manager, no errors anywhere to be seen (including the event viewer).

[giuspen]

I didn't really apply any change for this issue in cherrytree, I simply noticed that msys2 released a new glib2 package https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-glib2 (together with other updates) and rebuilt cherrytree with that. Unfortunately it doesn't look like windows 7 is supported anymore https://www.msys2.org/docs/windows_support/

[giuspen]

Actually I'm wrong, it is stated: Mingw Toolchains: MINGW32/MINGW64 environments allow targeting Windows 7+ still. All others allow targeting Windows 8.1+. And CherryTree is MINGW64 it should still be supported.

[B-Down]

And CherryTree is MINGW64 it should still be supported.

Be that as it may, I'm still not getting any response whatsoever from executing the .exe in that version.

I did try to copy some files over from the regular 1.2.0.0 (the *glib* files in mingw64\bin, then the .exe itself), to no avail.

Unless you have some way(s) of generating logs for it, I can't even tell you what could be the issue on my end 🤷 It would help to have feedback from other W7 users (@Atlntssplayer ?) as well.

[B-Down]

I did some deeper digging with the help of Dependency Walker, logs at the bottom of this message. The "tests" were on the latest 3 versions: 1.1.4.0, 1.2.0.0, 1.2.0.0-13.

I'm not a developer in any capacity (more so on Windows), so the depth of my "analysis" is limited.

Points of interest:

• All 3 versions:
  • IESHIMS.DLL and API-MS-WIN-CORE-WINRT-L1-1-0.DLL are said to be missing on my system...
    • I have a number of IESHIMS.DLL files on my system, just not in system32
    • As far as I can tell, API-MS-WIN-CORE-WINRT-L1-1-0.DLL is related to W10
  • In any case, CT works just fine (well, anything prior to 1.2.0.0-13 😁) without them being loaded
  • I "highlighted" error messages in the log files with blank lines, so they'd be easy(ish) to find without resorting to search
• 1.1.4.0 - 3 errors:
  • 00:00:01.607: GetProcAddress(0x0000000077550000 [KERNEL32.DLL], "GetSystemTimePreciseAsFileTime") called from "LIBWINPTHREAD-1.DLL" at address 0x000007FEF6869721 and returned NULL. Error: The specified procedure could not be found (127)
  • 00:00:01.779: GetProcAddress(0x0000000077550000 [KERNEL32.DLL], "SetThreadDescription") called from "LIBGLIB-2.0-0.DLL" at address 0x000007FEC6069A20 and returned NULL. Error: The specified procedure could not be found (127)
  • 00:00:02.808: LoadLibraryW("api-ms-win-core-winrt-l1-1-0.dll") returned NULL. Error: The specified module could not be found (126)
  • When closing the program, GDBUS.EXE exits with O
• 1.2.0.0 - 2 errors:
  • 00:00:01.779: GetProcAddress(0x0000000077550000 [KERNEL32.DLL], "SetThreadDescription") called from "LIBGLIB-2.0-0.DLL" at address 0x000007FEC6036F40 and returned NULL. Error: The specified procedure could not be found (127)
  • 00:00:02.762: LoadLibraryW("api-ms-win-core-winrt-l1-1-0.dll") returned NULL. Error: The specified module could not be found (126)
  • When closing the program, GDBUS.EXE exits with 3
• 1.2.0.0-13 - 2 errors:
  • 00:00:01.778: GetProcAddress(0x0000000077550000 [KERNEL32.DLL], "SetThreadDescription") called from "LIBGLIB-2.0-0.DLL" at address 0x000007FEC6B06E10 and returned NULL. Error: The specified procedure could not be found (127)
  • 00:00:02.761: LoadLibraryW("api-ms-win-core-winrt-l1-1-0.dll") returned NULL. Error: The specified module could not be found (126)
  • The program automatically closes itself after about 10 seconds, and GDBUS.EXE exits with 0

depwalk_CT_1.1.4.0.txt depwalk_CT_1.2.0.0.txt depwalk_CT_1.2.0.0-13.txt

[JGKle]

Should we be unzipping the build above over our installed CherryTree for now? Is that the best approach (until there's a new version with the fix)?

[giuspen]

@metal450 yes you can use https://www.giuspen.net/software/cherrytree_1.2.0.0+13_win64_portable.7z for the time being if you don't want to be nagged from the error dialog. @B-Down I will prepare a new development build with the latest msys2 distribution and link it here, let me know if it works any better. If not you should raise an issue with them reporting that it doesn't work anymore with Win7 while the website claims it should with MINGW64. I don't have a Win7 to test so I'm not the right person to raise such issue.

[JGKle]

Ok great thanks, will do.

Yeah the constant crash dialogs are a bit impactful, since it pops up after a short delay often when you're already typing in another program - & hitting "space" will then launch the full Visual Studio debugger.

[giuspen]

Latest build with up to date msys2 packages: https://www.giuspen.net/software/cherrytree_1.2.0.0+20_win64_portable.7z Please report if the gdbus.exe crash is confirmed gone (as it seemed already in 1.2.0.0+13 above) and if Win7 build is still broken.

[JGKle]

Confirmed the crash is gone (on Win10)

[B-Down]

Please report if the gdbus.exe crash is confirmed gone (as it seemed already in 1.2.0.0+13 above) and if Win7 build is still broken.

1.2.0.0+20 is functionally identical to 1.2.0.0+13 on W7 (CT doesn't launch "visually", while Dependency Walker shows the same couple errors and gdbus.exe exits peacefully after ~10 seconds).

I suppose I'll take it to MINGW64's devs then...

Out of curiosity, are you specifically using whatever new functionalities msys2 latest version(s) brought after 1.1.4.0 ? To be more specific, would you reckon there'd be a way to use some ye olde msys2 version (one that works with W7) on current (and future... ?) CT 1.2.0.0+x ?

[giuspen]

@B-Down AFAIK there is no stable version of msys2, it is a rolling distribution and there is no way to get back in time except for individual packages whose older versions are still available on their servers for a while. A ticket should be raised on https://github.com/msys2/MINGW-packages/issues to report that the latest MINGW64 builds of cherrytree are not running on Win7 and asking if this is expected / if they still plan to support Win7 as stated on https://www.msys2.org/docs/windows_support/ (Mingw Toolchains: MINGW32/MINGW64 environments allow targeting Windows 7+ still. All others allow targeting Windows 8.1+.) I can raise such issue if you prefer but they will likely ask logs that only you can then provide.

[B-Down]

Thanks for the links, I'll check all that when I get the occasion 🤞

AFAIK there is no stable version of msys2, it is a rolling distribution and there is no way to get back in time except for individual packages whose older versions are still available on their servers for a while.

I was merely thinking about (re)using any of the MSYS2 you've bundled with CT (pre-1.2.0.0, of course).