Hoping someone out there can help. I have a fairly simple piece of code for viewing files

System.Diagnostics.Process.Start(tFileInfo.FullName)

Basically passes the path of a file to the process and let Windows deal with how to open it. Have also tried

Dim myProcess As New System.Diagnostics.Process
      With myProcess
        .StartInfo.UseShellExecute = True
        .StartInfo.FileName = tFileInfo.FullName
        .StartInfo.CreateNoWindow = False
        .Start()
      End With

Works beautifully on my machine, but on three others i have tested it on, it opens PDF and TXT files no problem, but as soon as I attempt to open a Word file or an Excel file
I get "There is not enough memory or disk space to open Word" and similar in Excel if the application is not already open. If the Office app is open, the code works perfectly. Has anyone come across this before?

Dani AI

Generated

The error in this thread turned out not to be the Process.Start call but the Windows account environment. When Word/Excel fail to launch with the generic "not enough memory or disk space" while simple viewers open fine, it commonly means the Office app cannot complete per-user initialization for that account (profile paths, TEMP location, permissions, redirected/network profile, or problematic characters in the username). That also explains why handing the file to an already-running instance works: the existing process already initialized the profile and accepts the file.

Quick diagnostic checklist

  • Confirm the symptom while logged in as the affected user (double-click a .doc/.xls).
  • Inspect TEMP/TMP for that account: run echo %TEMP% %TMP% in a command prompt and verify the folders exist and the user can create files there.
  • Verify free disk space and any per-user quota on the system drive.
  • Run Word/Excel in safe mode (winword.exe /safe) to rule out add-ins or startup templates.
  • Rename the user Normal template (for Word: the Normal.dotm in the user Templates folder) to force a rebuild.
  • Test with a newly created local user that uses a simple ASCII name; if the problem disappears the profile/username is implicated.
  • Check for redirected or networked profile/Temp locations; older Office builds can fail when critical per-user folders are not local or contain unexpected characters.

Remediation and cautions

If the profile/username is the root cause, the safe path is to create a new user with a clean name, migrate data, and reconfigure Office settings rather than manually renaming C:\Users folders (that breaks registry/profile links). Back up user data and any important registry keys before migrating. Disabling add-ins, resetting the Normal template, and ensuring correct permissions on %TEMP% often resolve the problem without touching account names.

Solved this. Not related to the code at all, but the user name

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.