Mozilla quietly pushed out Firefox 143.0.1 last week, a micropatch with nothing more than a single sentence in its changelog: "Fixed a tab crash experienced by some users caused by DLL injection (Bug 1872261)." The root of the trouble — third-party DLL injection on Windows — has been haunting a subset of Firefox users since the major 143 update landed, and multiple crash reports point to Trend Micro's tmmon64.dll as the most frequent trigger.

What Actually Changed in Firefox 143.0.1

The update is as minor as they come: no new features, no security patches, no visible UI tweaks. It targets a very specific stability problem that emerged after Firefox 143 introduced internal code changes. Those changes, intended to harden the browser's sandbox or improve memory management, inadvertently created a collision with injected code from security and data loss prevention (DLP) tools.

Bug 1872261, the internal tracker referenced in the changelog, details the crash pattern. Mozilla's engineering team reworked how Firefox handles certain third-party code being loaded into its processes, likely by adjusting the timing of operations or adding safeguards to prevent corrupted state from injected DLLs. It's a patch that takes seconds to download and install—the installer size didn't change noticeably from 143—and it rolls out automatically through Firefox's built-in update mechanism. Users can force the update by navigating to Menu > Help > About Firefox.

For enterprise administrators, the usual advice applies: test in a controlled environment before fleetwide deployment, especially if your organization runs endpoint agents that use DLL injection.

How Security Software Ends Up Breaking Browsers

To understand why Firefox needed an emergency patch, it helps to know how modern security products operate. On Windows, antivirus, antimalware, and DLP suites often inject their own dynamic-link libraries (DLLs) into running applications. This technique lets them monitor file operations, clipboard activity, network connections, and other potentially sensitive events in real time.

Injection methods vary—SetWindowsHookEx, AppInit_DLLs, creating remote threads—but the result is the same: external code runs inside a browser's address space. Browsers, however, are not simple programs. Firefox uses multiple processes (UI, content, GPU, network) with strict sandboxing to isolate potential threats. When a security product's DLL hooks into private browser functions or alters execution timing, it can conflict with the browser's expectations. After an update like Firefox 143, which reworked internal code paths, those conflicting hooks can trigger crashes, typically manifesting as sudden tab closures without warning.

The culprit isn't always obvious. Crash reports available at about:crashes list the modules loaded when the failure occurred. Trend Micro's tmmon64.dll, a user-mode monitoring component, has surfaced repeatedly in these reports. But it's far from the only offender. Other endpoint agents from Symantec, McAfee, or custom enterprise DLP tools have caused similar instability.

Trend Micro’s tmmon64.dll: A Repeat Offender

Multiple community threads and enterprise support notes over the past few years have identified tmmon64.dll as a recurring entry in Firefox crash logs. The file is part of Trend Micro's endpoint security suite and is designed to provide behavior monitoring and data protection. When Firefox 143 changed its inner workings, tmmon64.dll's hooks appear to have stepped on freshly laid code, leading to tab crashes that could occur seemingly at random—especially on sites with heavy JavaScript or during file uploads.

Trend Micro is not alone. Other security vendors have also acknowledged compatibility issues after browser updates and released hotfixes. The common thread: the more aggressively a product hooks into applications, the higher the risk of collision when those applications update.

If you're running Trend Micro on a system that updated to Firefox 143 and experienced crashes, installing Firefox 143.0.1 is the first step. But you should also check for updated Trend Micro agents—the vendor typically issues compatibility patches for its endpoint software a few days after a browser regression becomes known.

What to Do If Your Tabs Keep Crashing

Most users will get the fix automatically and never see the crash again. But if Firefox 143.0.1 doesn't solve the problem, or you're dealing with a different injected module, here's how to stabilize things.

For Home Users and General Consumers

  1. Force the update: Go to Menu > Help > About Firefox. If 143.0.1 is available, it will download immediately. Restart the browser.
  2. Run in Safe Mode: If crashes persist, launch Firefox with add-ons disabled (hold Shift while starting Firefox or go to Menu > Help > Troubleshoot Mode). If the crashes stop, an extension or its interaction with security software may be to blame.
  3. Check your crash reports: Type about:crashes into the address bar and submit any recent reports. Then view the report details. Look at the loaded modules list. If you see a suspicious DLL (like tmmon64.dll, ntdll.dll from a non-Microsoft hook, or a vendor-specific DLL), search online for that filename plus "Firefox crash."
  4. Update your security software: Check for updates to your antivirus, DLP, or endpoint protection agent. Vendors often release compatibility fixes within days of a browser change.
  5. Temporarily disable real-time protection: As a diagnostic step, turn off your security software's real-time monitoring for a few minutes and see if the crashes disappear. This is not a permanent fix, but it confirms the conflict.

For Enterprise IT Administrators

  1. Deploy the patch in a test group first: Use a pilot group that mirrors your production environment—same OS versions, endpoint agents, and group policies. Monitor crash rates via about:crashes or enterprise monitoring tools.
  2. Coordinate with endpoint vendors: If inject-related crashes continue after applying 143.0.1, contact your DLP or endpoint vendor's support and request a compatibility update or hotfix.
  3. Leverage Firefox Enterprise Policies: If you need to delay the 143.x rollout until compatibility is verified, use the AppUpdatePin policy to stay on an older version temporarily. Alternatively, switch to the Extended Support Release (ESR) channel for longer-term stability on legacy systems.
  4. Enable the Content Analysis SDK: Firefox offers a supported, injection-free integration path for DLP solutions. Enable the Security.ContentAnalysis.Enabled policy and work with your vendor to switch their agent to this SDK. This eliminates DLL injection into Firefox entirely for content inspection use cases.
  5. Monitor crash rates: Use Firefox's built-in Telemetry or your own endpoint management tools to track crash reports and correlate them with recent updates or endpoint agent changes.

Here's a quick checklist:

  • [ ] Update Firefox to 143.0.1 on all affected machines.
  • [ ] Update endpoint protection and DLP agents to the latest versions.
  • [ ] If crashes persist, run Firefox in Safe Mode to see if the issue disappears.
  • [ ] Inspect about:crashes for injected DLLs like tmmon64.dll.
  • [ ] For enterprise fleets, enable Content Analysis SDK where DLP integration is required.
  • [ ] Use Firefox Enterprise Policies to control update timing if needed.

Mozilla's Long-Term Plan to Stop This Happening Again

Mozilla knows that reactive micropatches aren't a sustainable strategy. Over the past two years, the company has been developing a Content Analysis SDK that gives DLP vendors a documented, secure way to integrate with Firefox without injecting code. The SDK exposes an API surface that allows DLP agents to analyze content (file uploads, pastes, etc.) and make blocking decisions from outside the browser's process sandbox. It mirrors similar approaches already used by Google Chrome and Microsoft Edge.

For enterprises, enabling this SDK is a matter of setting a policy key in Firefox's enterprise configuration. Once turned on, compatible DLP products can hook into Firefox without the risks associated with user-mode hooking. The catch: vendors must adopt the SDK in their own products. So far, adoption has been slow, but Mozilla continues to invest in documentation and outreach to enterprise security partners.

Another piece of the puzzle is the Extended Support Release (ESR) channel. Firefox ESR provides a stable, long-life branch for organizations that can't keep up with rapid-release cycles. ESR versions receive security patches but no feature updates for roughly a year, giving IT teams time to test compatibility with endpoint agents. Mozilla recently extended support for legacy Windows and macOS versions on the ESR track, offering a temporary bridge for users who can't upgrade their OS immediately.

The Bigger Picture: A Fragile Partnership

Firefox 143.0.1 fixes one immediate headache, but the underlying tension won't disappear overnight. Modern browsers update every four to six weeks, and each release can tweak internals that are invisible to users but critical to security software that hooks into those processes. Security vendors, for their part, must test their agents against these rapid updates and push out hotfixes on short notice—a coordination dance that often breaks down.

The disruption caused by DLL injection isn't limited to Firefox: Chromium-based browsers have grappled with identical issues, and Microsoft has faced compatibility problems with Windows Defender's own hooks. The industry consensus is moving toward documented integration APIs (like the Content Analysis SDK) and away from invasive injection techniques. But until the majority of endpoint products make that shift, crashes like the one patched here will recur.

For the average Windows user, the lesson is clear: next time your tabs suddenly crash after a browser update, check your security software first. For IT pros, the takeaway is even sharper: proactive vendor coordination and a strategy to move away from DLL injection are the only long-term answers. Mozilla's quick fix this week bought everyone some time—but the real solution lies in an architectural shift that's still unfolding.