This blog covers the OneDrive error “Sorry, there was a problem signing you in. Please try again in a few minutes.” It explains why it happens, how special characters in the user’s display name trigger it, and what we found through Procmon traces…. and of course, how to fix it !
Introduction
It started with a few users who couldn’t sign in to OneDrive anymore.
The OneDrive error message was simple but useless:
“There was a problem signing you in. Please try again in a few minutes.”
Everything else worked fine. Teams, Outlook, and Edge signed in without an issue.
Only OneDrive refused.
Some users could sign in instantly, while others failed repeatedly. They all had the same OneDrive version, and the same policies applied. It’s obvious we tried the basic steps first.
- Reinstalling OneDrive
- Clearing the OneDrive cache,
- Resetting credentials,
- Performed onedrive /reset
- We even removed and re-added the accounts.
Nothing helped, and the OneDrive error: There was a problem signing you in. Please try again in a few minutes. It was still shown when signing into OneDrive.
The Symptom
The moment we opened OneDrive and accepted the credentials, it just stopped.
No error codes. No hints in the OneDrive logs (as they are unreadable by humans… wait… 🙂 ) . No signs of a network or authentication issue. All authentication calls succeeded, indicating the failure occurred locally after credentials were processed.
Comparing Users
Why did it only happen to some users and not others? We started comparing the affected users who failed with those who didn’t have the issue. Same configuration, same licenses, same policies. After some testing, it became clear that every failing account had a special character in its display name.
Names like Rudy Öoms and José García failed every time.
Names like Rudy Ooms and Jose Garcia worked.
Good to know is that: The display name in Entra will be used as the folder name when your user profile is created on the device.
That pointed to a problem in how OneDrive handled extended characters during initialization. To test it, we changed the display name in Entra to plain ASCII and tried again.
It worked, but only partly. OneDrive still pointed to the existing Windows profile folder that contained the special character.
We renamed the local profile folder and updated the ProfileImagePath in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>
to match the new folder name. After that, OneDrive finally signed in. It worked, but it wasn’t the solution we were looking for. Changing display names in Entra just to make OneDrive work feels wrong, and renaming local profiles through the registry is messy.
Still, it confirmed that the problem was buried deep in how OneDrive reads profile paths and handles encoding. From there on, we started to wonder if this issue affected all OneDrive versions
Watching the OneDrive Error with Procmon
Once we could reproduce it, we started a Procmon trace and launched OneDrive. The moment the OneDrive error appeared — “There was a problem signing you in. Please try again in a few minutes.” — the Procmon trace told the story. OneDrive tried to open a configuration file linked to the user account
C:\Users\RudyÖoms\AppData\Local\Microsoft\OneDrive\settings\Business1\1b1c0170-bc3c-4718-b17c-60155fd19b80.ini
Then it tried again, but in a folder that didn’t exist
C:\Users\RudyȮims\AppData\Local\Microsoft\OneDrive\settings\Business1\1b1c0170-bc3c-4718-b17c-60155fd19b80.ini
As shown above, Procmon logged NAME NOT FOUND for each lookup using the corrupted path. The folder itself hadn’t changed. OneDrive was just searching in the wrong place.
During initialization, it built a malformed version of the username with invalid Unicode characters and looked for the .ini file there. Since that folder didn’t exist, OneDrive couldn’t read or create the configuration file, and the sign-in failed right after authentication.
With the cause identified, the next step was to check if this behavior was new or version-specific.
OneDrive Older Versions
After analyzing the Procmon trace and confirming the folder lookup failure, we started testing older OneDrive versions. After trying multiple versions, it became clear that something had changed in the September OneDrive builds.
The first thing we tried was installing an older OneDrive build.
After uninstalling the current version and reinstalling the older one, it updated itself almost immediately when launched, exactly as expected. Unfortunately, that automatic update brought the issue right back, showing the familiar “Sorry, there was a problem signing you in” error.
We removed OneDrive again and configured the deferred update ring to slow down automatic updates:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\OneDrive
DWORD: GPOSetUpdateRing = 0
That stopped the auto update long enough for the client to function across several restarts, but after roughly 24 hours, OneDrive updated itself again and the problem returned.
Trying to Fix the OneDrive Error
We started testing older OneDrive builds to see if the problem was introduced recently. After trying multiple versions, it was clear that something had changed in the September builds.
To confirm what OneDrive was missing, we manually created the folder C:\Users\RudyȮims\AppData\Local\Microsoft\OneDrive\settings\Business1, and launched OneDrive again.
OneDrive still failed to sign in with the error: There was a problem signing you in. Please Try again in a few minutes.
Next, we created an empty .ini file named exactly like the one OneDrive was looking for
That did the trick. OneDrive finally launched and signed in. So the missing .ini file was clearly part of the problem. The next question was simple. What is that .ini file based on
The Missing Link
The name of that .ini file wasn’t random. It matched the unique identifier assigned to the user in Entra.
That same identifier also appeared in the registry under: HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\<UserGUID>
That connected the dots.OneDrive tries to locate a settings folder tied to that user’s Object ID.
Because of the encoding mismatch in the local profile name, OneDrive ends up looking for a folder path that doesn’t exist and fails to locate or create the .ini file.
Automating the OneDrive Fix: There was a problem signing you in
By now, we knew that manually creating the folder and .ini file worked, but it wasn’t practical.
We built a PowerShell script to automate it.
The script checks for any user folders in C:\Users that contain non-ASCII characters.
If it finds one, it generates the corrupted folder path that OneDrive expects and builds the full structure under: \AppData\Local\Microsoft\OneDrive\settings\Business1.
It then looks up the user’s unique identifier in HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\Policies, and creates an empty .ini file using that ID.
That small script gives OneDrive what it expects and allows it to initialize successfully even when the display name contains extended characters.
It doesn’t fix the root cause, but it helps affected users sign in without renaming their account or recreating their profile.
Why OneDrive errors out with: There was a problem signing you in
The real cause is how OneDrive handles Unicode when it processes the display name received from Entra. Entra sends the display name in UTF8, which is perfectly valid.
The problem is that OneDrive doesn’t consistently decode that text as UTF8.
Instead, it depends on the system’s active locale and code page to interpret those bytes.
On systems that still use the legacy Windows1252 code page, OneDrive reads those UTF8 bytes as if they were ANSI characters.
That is where everything goes wrong. The Ö in Rudy Öoms becomes a pair of unrelated symbols, often Ö or Ȯ, depending on how the bytes are interpreted. OneDrive then uses that corrupted name to build part of its local configuration path.
So while every other Microsoft 365 service handles the UTF8 display name correctly, OneDrive fails because it reads it through the wrong code page.
The result is a folder path that doesn’t exist, and the client never manages to find or create the .ini file linked to the user ID. This is not a localization issue in Windows itself; it’s OneDrive misinterpreting the UTF-8 display name it receives from Entra.
Fixing It by Changing the System Locale
Now that we know the problem is caused by OneDrive decoding UTF8 names using the wrong system code page, there’s actually a cleaner fix than creating folders and .ini files manually.
By changing the system locale to use UTF8 for non-Unicode programs, OneDrive will correctly interpret display names like Rudy Öoms the way Entra sends them.
To do that:
- Open Settings → Time & Language → Language & Region
- Select Administrative language settings
- In the Administrative tab, choose Change system locale…
- Check the box “Beta: Use Unicode UTF-8 for worldwide language support”
- Reboot the device
After restarting, you can verify the change in PowerShell: [System.Globalization.CultureInfo]::CurrentCulture.TextInfo.ANSICodePage
If it returns 65001, the device is now using UTF8 instead of Windows-1252. This tells OneDrive to decode Entra display names properly, preventing the broken folder path and .ini file lookup entirely.
Closing
The entire issue comes down to character encoding and how OneDrive misinterprets it.
Entra delivers UTF8 names, but OneDrive decodes them using the wrong locale, creating paths that don’t exist. When that happens, the client cannot find or create the .ini file associated with the user ID, and sign-in fails before initialization completes.
Until Microsoft updates OneDrive to handle Unicode consistently, users with extended characters in their names will keep running into this invisible wall.
A single Ö in a display name can stop OneDrive from launching, and now we know exactly why.