00148303, 00148302
SedonaOffice Slowness in Native Windows 11
This may present as logins taking longer than 10 seconds to login and or Jobs in Job Queue are significantly slow to open and also Applying Changes
SEDONAOFFICE.EXE connects to a local server using its hostname and it will resolve that hostname listed in the registery - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sedona Development Company\Client
SQL servername in the ServerName Field & SQL ServerName after “Data Source =” in the connection string
You can test pinging the servername from the impacted workstation to see that it resolves the name to the correct IPv4 address of the SQL server. Also ensure that the customer is not using a VPN between the workstation and SQL server as that introduces latency and is not supported.
Typically if the IP is not returned properly long - the customer IT would need to ensure the workstations have a DNS entry in the hostfile C:\Windows\System32\drivers\etc to point to the proper IP
-or-
Adding a Reverse DNS lookup - PTR (IP -> hostname) to their DNS server
What happens under the hood in Windows local LAN environments:
- Windows performs a forward DNS lookup (hostname → IP) — that part usually succeeds quickly.
- Immediately afterward (for security, logging, and network location checks), Windows 11 does a reverse DNS lookup (IP → hostname) on that address.
- If a reverse lookup (PTR record) is missing from your internal DNS server or the DNS server is slow to respond with “no record” (NXDOMAIN), the DNS Client service (Dnscache) inside svchost.exe (NetworkService) blocks the calling thread for several seconds (typically 5–30 seconds in bad cases).
During that block, your entire program freezes — that’s exactly what the Wait Chain showed.
Why Windows 11 is much worse than Windows 10 forthis item
- Starting with Windows 10 20H2/21H2 and especially Windows 11 (22H2/23H2/24H2), Microsoft increased the DNS timeout and retry behavior for reverse lookups on internal networks. They made it more aggressive about trying IPv6, multiple DNS servers, and waiting longer for an authoritative answer (to improve security and compatibility with modern networks/domain setups).
- Result: On identical network/DNS conditions, Windows 10 often timed out after ~1–2 seconds or did the reverse lookup asynchronously. Windows 11 frequently waits 10–30 seconds synchronously → visible freeze in apps.
- This change is intentional (documented in some Microsoft release notes around network stack hardening), but it broke thousands of legacy/local apps that assume quick local resolution.
Why some Windows 11 machines (previouslyupgraded-from-Win10 ones) don’t show the problem
When you do an in-place upgrade from Windows 10 → Windows 11:
- Certain old DNS and network stack registry settings are migrated and preserved.
- In particular, older values for DNS timeouts, reverse-lookup disabling flags, or cached network profiles often carry over.
- The network adapter’s cached name resolution and network location profile (Private/Domain) is already established, so NlaSvc (Network Location Awareness) inside the same svchost doesn’t trigger extra reverse lookups on every connection.
- Clean-installed Windows 11 (or reset/new machines) start with the stricter 2022–2025 defaults → longer blocking timeouts and no “forgiving” legacy settings.
That’s why the exact same app + same network + same DNS server behaves perfectly on upgraded machines but hangs on clean Windows 11 installs.
