nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Windows] v15.80.4

ElifG

Operating system - Windows

Version - 15.80.4

Release date - 2026-07-28

New features

Added support for Admin settings, device management, Single-Sign-On (SSO) and Microsoft LAPS integration to the Hybrid Conditional Access.
Tensor-licensed customers can now forward their local microphone and camera to the remote device, enabling them to join meetings or use applications that require a camera and microphone directly from a remote session.
Auditability for account security has been improved. Password changes will now be logged as separate events.
The user creation date and last active information have been added to the User Details panel, giving administrators quick insight when reviewing user profiles.
Permission handling for user groups has been improved. Actions such as creating, viewing, updating, and deleting user groups are now controlled by assigned permissions, ensuring clear and consistent access management.
Customers can now create Conditional Access rules using Company Profiles, enabling secure access scenarios involving trusted third-party organizations, such as external support providers using TeamViewer. A new External Company option is available in both the Source and Target fields during rule creation, allowing administrators to specify a Company Profile name and apply the rule to users associated with that external organization.

Improvements

TeamViewer now natively supports Windows on ARM devices for both TeamViewer Remote and TeamViewer (Classic). Its functionality matches the existing Intel-based versions, ensuring a consistent experience across device architectures.
The width of the in-session Tia side panel has been increased to provide a more comfortable experience when interacting with chat.
Session connections using Windows authentication are now available from both the command bar and the context menu on the Service Queue page.
The unattended access text in the Classic Host has been updated to align with TeamViewer Remote. The revised wording more clearly indicates that the device is managed by the company, reducing potential confusion around manager-based access and improving consistency between TeamViewer Remote and Classic.
User management has been enhanced with sortable columns for User Groups and User Roles, improving navigation and data visibility.

Bugfixes

Fixed a bug that caused connection issues when a connection was initiated via Easy Access.
Fixed a bug that prevented access to the 3-dot menu on the Service Queue page.
Fixed a bug that caused the start screen to remain in an infinite loading state, preventing users from accessing the sign-in page.
Fixed a bug where pressing the Backspace key removed the entire input instead of only the last character when using certain Asian languages.
Fixed a bug that could cause the collapsed in-session toolbar to disappear after opening a side panel.

Find more posts tagged with

Comments

Marie Claude

Hi @Hstein,

Thank you again for the detailed update and for all the time you've invested in documenting your findings and troubleshooting the issue.

It's great to hear that you're already working closely with J.N. We also appreciate you sharing your observations with the TeamViewer Community and keeping everyone informed along the way.

We're looking forward to hearing what the investigation uncovers, and we'd love to hear back from you once there's an update.

Best,

Marie Claude

Hstein

Hi Marie,

Thank you for reaching out! Indeed, I already have an open ticket ([removed per Community Guidelines] ) and have been actively working with your support engineer, J.N. I had actually provided initial log collections through the ticket prior to posting here to give other community members a heads-up on what I was encountering.

Since my initial post, I followed J.N.'s instructions to perform a complete, clean uninstall—manually purging all user and machine registry folders, rebooting, and installing a fresh build. Leaving all local settings at their defaults, I connected to a remote host on my local network. The connection worked, but upon closing the session I observed two of the four cloud TCP sockets in a CLOSE_WAIT state (why this is consequential is omitted here) — re-opening a session the second time, the Management Console GUI crashed in the exact same manner before the clean install. I have gathered the updated logs (with advanced network analysis enabled) and am sending them directly to J.N. for review.

As it stands, my current workaround requires manually terminating the TeamViewer_Service.exe, the GUI process (if it hasn't crashed already), and crashpad_handler.exe. Once the processes are restarted, four clean TCP connections establish to your cloud infrastructure. However, as soon as the first session is closed, two of those socket connections stall in a CLOSE_WAIT state, leading to the GUI crash on subsequent interaction.

I suspect many users who encounter this following the latest update might initially write it off as a typical glitch or a "hosed up" end-user machine—just as I did for nearly a full week on several computers. But when it started happening on a fresh install of Windows 10 latest for a client machine, and when I was unable to connect to a few clients needing my attention, I began to explore aggressively for "what changed" and how can i work around this until it is fixed. As more people hit this build, I believe the support queue will show a common denominator: G1!!!CRASH: Heap corruption at 00007FFB68E8F509 (or similar offsets) logged right during the UI teardown sequence.

I will be sure to keep the community updated as J.N. and the engineering team investigate ticket #[removed per Community Guidelines] .

Best regards,

H Stein

Marie Claude

Hello @Hstein,

Thank you for taking the time to put together such a detailed post and for documenting your findings so thoroughly. We would, however, need more details to find this issue's root cause. As such, we recommend sharing these occurrences with Customer Support by opening a support ticket. You can do so by starting a ticket as described in the link below.

Open a support ticket

The most effective way to share as much information as possible with the support team would be by enabling Verbose logging by following the steps below:

1. Open your TeamViewer Full Client and access settings by selecting the Gear icon next to your profile picture on the upper right corner.

2. Go to Advanced settings.

3. In the Advanced tab, scroll down to the Show log file section.

4. Make sure Enable logging is enabled (with a checkmark) and select Verbose logging in the drop down menu.

5. Click OK to save.

Once Verbose logging is enabled, please continue using TeamViewer until one of the described behaviors occurs. After that, collect the logs using the Support Collector, as outlined in the Knowledge Base article below, and add these to your ticket.

Collect log files with the TeamViewer Support Collector

Please keep us updated on the outcome and don't hesitate to share further findings on the TeamViewer Community.

Best,

Marie Claude

Hstein

TITLE: TeamViewer 15.80.4 repeatedly crashes with heap corruption during remote-session startup or teardown.

I am seeing a serious and repeatable stability problem with the TeamViewer 15.80.4 Management Console/Application on my controller computer.

The symptoms vary slightly from one attempt to another:

A remote session remains on a black screen or “Initializing Session.”
The TeamViewer interface becomes unresponsive while opening a session.
A session may open successfully once, but the Management Console freezes or crashes when the session window or tab is closed.
After the crash, the TeamViewer service may continue running while the interactive TeamViewer.exe process has terminated.
crashpad_handler.exe may remain running after the TeamViewer interface has crashed.

This has occurred while connecting to more than one remote computer, so it does not appear to be limited to one remote endpoint.

The most significant entries in the controller’s TeamViewer logs are repeated instances of:

CRASH: Heap corruption ... Exception Code: 0xC0000374

The failing addresses vary because the module is loaded at different base addresses, but many of the crashes consistently end in:

F509

In several occurrences, the heap corruption is immediately preceded by Sciter UI errors such as:

SciterUI[script]: TypeError: not a function

at componentWillUnmount

The errors reference multiple TeamViewer session-interface components, including dropdown controls, widgets, toast notifications and session animations. The heap corruption then occurs milliseconds later.

However, the crash is not limited to session teardown. In another controlled test, the Management Console crashed during session initialization before the remote desktop was displayed.

I tested two plausible workarounds separately and restarted TeamViewer between tests:

Disabled hardware acceleration

The logs confirmed that TeamViewer switched from DirectX to GDI rendering. TeamViewer nevertheless produced the same 0xC0000374 heap-corruption crash. Therefore, the crash is not dependent upon DirectX or the graphics driver.

Disabled “Open new connections in tabs”

The next session opened in a separate window as expected, but TeamViewer still froze and produced the same heap-corruption signature during session initialization. Therefore, tabbed-session teardown is not required to trigger the crash.

The network evidence also argues strongly against this being a router or connectivity problem. During affected sessions, the TeamViewer service reported a direct UDP connection, approximately 1 ms latency and estimated capacity around 90 Mbps. The service remained alive and continued processing the network session after the TeamViewer GUI process had already corrupted its heap and terminated.

Before the update, the same controller installation was operating under 15.79.4 and successfully creating screen streams and completing remote-control sessions. The instability became apparent after the move to 15.80.4. The older logs contain successful StreamType_Screen initialization and normal client-connection processing, while the newer failures repeatedly end in GUI-process heap corruption.

I recognize that this does not prove the exact defective function without TeamViewer’s private symbols. Nevertheless, the evidence strongly suggests a 15.80.4 application regression or memory-management defect in the Management Console/session UI rather than a networking failure or an ordinary configuration problem.

Anyone experiencing similar symptoms may want to search their TeamViewer log for:

CRASH: Heap corruption

0xC0000374

componentWillUnmount

TypeError: not a function

Activity timed out: Initializing Session

TeamViewer terminated unexpectedly

Has anyone else observed this specifically after installing 15.80.4?

I would also appreciate confirmation from TeamViewer as to whether engineering is already investigating this crash signature and whether an official 15.79.4 installer and supported downgrade procedure are available while the issue is being addressed.

Thank you,
H Stein (Business Edition)

Up to speed

See what's new at TeamViewer

Read now

New feature spotlight

Learn more about the latest feature we’ve released.

Learn more

Tip of the month

Discover quick, practical tips to get more out of TeamViewer each month.

Learn more