I have a really weird bug that seems to be occurring within the gui64 framework on windows server 22 that isn’t happening on any other windows flavors.
Has the team made the .pdb files available for the frameworks? I can’t reproduce the bug during startup on a new project so I can’t really make a issue for it without going deeper to work out what’s going on. The project that is having the issue is rather old and API 1 so that may have something to do with it (and stands no chance of being updated to API 2.0 anytime soon)
The actual main thread looks like it never quite reaches its sleep state - task manager reports the core as 100% and the cycles are going up in the billions after a few seconds of running.
Adding a timer of period 1 with a action of doevents(1) resolves it (purely as its distracting it from doing whatever its trying to do)
That sounds like the app is responding to an overwhelming number of requests.
It would be helpful to know what version of Xojo you are using, what version of Windows Server, whether the app is Standalone or CGI and whether or not you are using a front end like IIS, Apache or Nginx and what the config is if you are.
It is indeed a Desktop Application but its being deployed as a Service using win32 and some thread magic that took a little bit of creativity to pull off. (There is a single window that exists in window session 0) All other Windows OS’s have been totally okay with it Win 7/10/11/2012/2016/2019 - only 2022 (not tried vnext yet) is having an issue with it. It seems to be getting stuck within the winCRTMain after/during an enableMenus call to the framework.
I’ve full disabled all that the application does - removed the windows - disabled all threads so that there is just the standard xojo main thread doing all the normal xojo backend - its not in our code where the actual/true main thread is getting caught up - it’s a level above (below?).
It’s only with this specific project too - my standalone project that just runs a 2.0 API gui app as a service doesn’t get caught in the 100% cycle and converting that into the 1.0 API also doesn’t have any issues.