-
a local “inprogess” fit file is created, but the file stops recording after i.e. 20km (of a 100km ride)
-
timestamp is 1-2 hours before saving the actual ride. the file does have 100-150kb size so it started to record.
-
other rides before and after record fine, the issue is completely random
-
and activity appears in my Zwift feed, but can not be opened (no file to download). It is displayed with correct lenght, duration, and score bord. Screenshots can not be viewed on companion but appear to exist (only can not be viewed because the ride can not be accessed, red error flag “activity can not be displayed” - same via browser.
-
the local file is broken and if fixed with 3rd party software, incomplete, matching the time stamp that is way before the activity was finished
-
Zwift seems to stop recording to the local file, and does not create a downloadable file on the server.
-
folder permissions are fine
-
it never happend before patch changed folder structure, though that new folder is populated and as I said most activities save a complete file and sync
-
red error flag activity can not be displayed via companion. blank page when opening ride via feed in browser. ride shows in the feed though with correct lenght
-
In this case the ride was a group ride, then riding on for another 1,5h. The group ride shows with all stats on ZwiftPower
-
there is no sync to any other platform (because there is no complete file created)
-
the existing local file that exists stopped recording after 20-30 minutes. It can be repaired but is incomplete.
-
nothing points towards a local problem, a permission problem with the folder, a problem with the zwift installation is unlikely as the issue is random, an issue with zwifts permissions when started is impossible, as it creates a file and performs all actions normally as usual, and pretends to save the activity at the end
-
issue was introduced with either release **(159921) or (159238)
** -
also this issue happens for quite a lot of other people. In my feed I discovered I get the same “ride can not be displayed” error for some of my friends ride - most of their rides can be viewed. It would at least seem that this issue is more widely spread and (most likely) related to a bug in the recent updates.
This seems to fit the “Endian 38” Malformed Write Bug related to Windows Launcher. That explains why some users are spared and why it only happens sometimes.
-
The Symptom: The file exists and has size (e.g., 150KB), but because the “End of File” marker was never written or the header is garbled, Zwift’s own servers can’t parse it when you hit “Save.”
-
Why it’s intermittent: It seems tied to the Video Screenshots feature. Even if you don’t manually take a shot, the “Auto-Screenshot” or “Video Highlights” feature (if enabled) can lock the file buffer. If the video encoder glitches, the
.fitfile write-stream often hangs with it.
So currently the Windows update that adresses long file write and long Zwift activities “collide”.
Again another broken acticity. Afterwards my feed did not load for a while.
Tested everything from reinstalling zwift, to repair install of windows… starting zwift as admin, starting it with legacy folder parameters. Nothing helps. The files are created, but sometimes Zwift stops updating them.
Still not 100% sure what is causing this and why it started to happen out of nowhere..
Have you tried disabling video screenshots in zwift settings?
I wonder if Zwift has any statistics as to how many users actually use the video screenshots? It seems like one of the most common bug ‘fixes’ I see is ‘turn off video screenshots’. This just seems like a feature that should be removed altogether.
What I observe is that the feature works well on Apple devices, but sometimes not on Windows where there is far more variation
I will try this, the root cause could indeed be indeed the video function, but it is also related to the teleport. And using the latest Nvidia driver, the behaviour started occuring after 24th of March, so I´ve been analyzing the logs (Nvidia 4070 super is the GPU in this case)
1. The Crash Sequence (Driver 591.86):
Plaintext[16:16:15] FB resize: 0 x 0 [16:16:15] GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT [16:16:16] GL error GL_INVALID_FRAMEBUFFER_OPERATION [16:16:16] INFO LEVEL: [VIDEO_CAPTURE] Zwift isn't visible, resetting [16:16:16] [GN]: invalid light removal (Repeated 1000+ times)
2. System Context:
Plaintext[Graphics Vendor] NVIDIA Corporation [Graphics Renderer] NVIDIA GeForce RTX 4070 SUPER [Graphics Version] 4.6.0 NVIDIA 591.86
3. The Stable Baseline (March 22 - Driver 581.08):
Plaintext[23:41:39] [GAME]: Shutdown [23:41:39] [GameState] SendApplicationSessionEndEvent [23:41:39] [VIDEO_CAPTURE] VideoCapture::DisableVideoCapture(false) [23:41:40] [FileIO] ZFile::SafeClean: SUCCESS
Earlier logs (pre-March 24) show that GL_INVALID_FRAMEBUFFER_OPERATION errors were occasionally triggered by teleports even on older drivers, but the game was able to recover. Since the update to NVIDIA 591.86, these errors now trigger an infinite loop that ‘zombies’ the game = file is no saved. Usually the file would have saved anyways when exiting ride, but on my system the link to “MS game bar” was broken.
Restoring the Windows Game Bar doesn’t stop the crash, but it does allow the Zwift background service to successfully recover and sync the FIT file once the game is closed, which was impossible when the Game Bar was missing/broken.
So now I roll back to the previous driver version as these seem to run Zwift more stable. I will disable the video feature for now, although it has worked for many month with no issues (and I´d miss it but I´m missing my completed activities more!) And I´d be mad if that happens during a super long ride.
It seems to be a very bugged feature indeeed. Looking at the logs it caused problems before but the engine recoverd (the new driver made it fail to do so) = it has been working, sort of. It did at least not cause any loss of files, but the logs show it often triggered errors. I have been using the feature for a long time and enjoyed using it. I will disable it for now, untill I am sure this works. I will report if this resolves it. I DO think the current Nvidia driver release in combination with Zwift is the bigger issue. This is something Zwift Dev team should maybe look into. This might explain why other people seem to have the same “broken rides” in their activity (no data but a ride shows up, red error flag when trying to open. Evidence this is not just me)
this is the conclusion of analyzing logs (successfull saves) and unsucessfull ones. Unsuccessfull ones only after the driver update (did not happen the last 300 rides before!) The trigger seems to be the teleport (causing a video capture reset) So turning this feature OFF should certainly help ?! I will test this now.
Zwift does not benefit from Nvidia driver updates and the one provided with Windows by Microsoft will usually be your best option when seeking stability. I would never bother tracking Nividia driver updates unless you have some other reason (ie, not Zwift)
I would not blame this entirely on Nvidia. The trigger event was there before and it seems to be part of the teleport and video screenshot features. The previous driver could just handle the error better and did not cause it to crash. That still means there is an error in the code. The rollback to the last revision is in this case ok for me if it helps, but the issue has to be adressed to make those updates work in the future.
It is common and best practice to keep Nvidia drivers up to date, and usually this is also the recommendation from Zwift. Using the driver provided from Mircrosoft without additional features and software for a high end gpu is not really an option.
I’m not blaming anyone since I don’t know who is responsible for the bug, but any machine with an Nvidia GPU that is devoted to running Zwift can simply stay with the driver Microsoft provides, update it when Windows Update provides a new one. That is the best practice for a machine that is dedicated to Zwift. If you use it for other current gaming titles then you probably have little choice about running more recent drivers. I suggest reverting to the Microsoft provided driver as a troubleshooting step after you test it with the Video Screenshots feature disabled.
who has a machine that is dedicted to zwift? No not a gamer, this is my workstation.
More news for you: the video record is NOT the trigger. It is changing from window to fullscreen mode. This is a typical and very old OpenGL problem. Well maybe because OpenGL is just ancient from todays point of view?
GL_INVALID_FRAMEBUFFER_OPERATION. → this stops in my current logs without full screen mode. In window mode there is no more " FB resize: 0 x 0." errors occuring. These were present in all my logs, not even the broken rides. This is an ongoing issue but the previous driver has handled it better. it sounds to me this is rather about how well the problems in the code are handled by the GPU driver and system, and in what settings you can evade this.
Running the game in window mode causes 4-5% times the normal CPU load. It seems not like the best option either but with that, the video screenshot function runs, the log stays free of errors. Disable video function and run in fullscreen: still errors, but it seems it somehow runs “stable” enough to save a file later. I will test this as running in window mode is really the last resort (keeping a 12core R9 at 12-13% for the long rides I do is..let´s say it not desirable)
If windowed mode is the workaround, you could use Borderless Gaming to make it appear full screen.
Yes many people have PCs dedicated to Zwift but it’s OK if you don’t, it just changes the advice a little.
If you want Zwift to look into the bug, you should contact them.
No it is not a workaround to have this kind of CPU load for zwift running, to tackle an issue that did not exist before. No trouble for one year. The new Nvidia driver is not the root cause, that is a very dates graphics interface with the full screen toggle to desktop not adressed. THAT is what is causing the errors. The pattern goes through the previous logs. The errors presists, just did not cause the driver to crash. Any fullscreen mode to desktop toggle, teleports, and the video function as well all can cause engine hickups. This raises some questions. If Zwift had life file writing or any kind of “file health check” for the ongoing fit file…or something like server sided caching that helpst to prevent “broken activites” … would be a dream. Most likely will remain one.
If you want Zwift to look into your logs and try to diagnose the cause, I recommend reporting the problem to them. The forum is not a reliable way to get action on a bug.
I have done that already thanks
It took me several messages to get around the auto responding AI agents and hopefully now a real person looks into this.
After four years of Zwift with ups and downs in terms of “stabilty” patches and issues afterwards,
close to the point where I think I´ve had it and it´s time to move on. For two weeks now, half of my rides get corrupted, not uploaded, half of the rides missing, The experience is beyond frustrating and anything I´ve tried and investigated in the logs has not helped. Zwift support answered with 3 prefabbed AI mails, my case was escalated…but nothing happend.
My new computer was running Zwift just fine for a year, till the last patches from Zwift. I first thoght I changed something - new grpahics driver, rolled that back, and tested about everything possible.Thought it was fixed - finished a 200km ride. No issues..but analyzing the log showed: only the strong cpu kept the session alive, it was full of errors. Though the local fit file updated, and I got a complete fit file. No sync. Ride shows on companion, can not be downloaded or viewed - if it can be viewed, the file is corrupted. The latest NVIDIA driver (for 4070 super) makes the issue worse (no rides can be recovered at all) but even with the previous 2025 driver that worked fine till this day, the issues presist. Video functionis turned off, has nothing to do with it. Changing tab to windows makes the issue worse and CAN trigger it.
However, today, no tab changes, video off, old Nvidia driver, everything as it as for the last 15 month. Except for Zwift, with recent updates to the folder structure. Yes, files are created, some are saved, but 50-70% of the rides are now broken.
The “support” that was once very good, is now mostly AI based, ignoring the reported issues - responding with the usual “default” answers (turn off vide, reinstall zwift…and so on). My log findings and the errors are ignored.
Usually part of the game engine will shut down somwhere during the ride after
[22:13:31] GL error GL_INVALID_FRAMEBUFFER_OPERATION[22:13:32] GL error GL_INVALID_FRAMEBUFFER_OPERATION
After that, no more communication with the server
[22:16:11] [ERROR] Curl error: [28] 'Timeout was reached'[22:16:32] [ERROR] Curl error: [56] 'Failure when receiving data from the peer'
The curl errors are braking the ride. There is tons of different errors, and wild error loops that canbe triggered by teleporting or taking a video screenshot. Both things do make the issue worse, but the unability of the engine to recover and write a proper fit file is new (after March updates)
Sorry that’s happening, that sucks!
I’ve not had any of these issues, so it is hard for me to say that it is due to Zwift’s updates, but I also haven’t had a reason to look at log files, so it is possible my logs are filled with errors too? I’ll have to go have a look.
Hopefully someone from support sees your message here and can provide some individual assistance that isn’t garbage Ai.