Directory.GetFiles with a zero-match search pattern throws FileNotFoundException (naming the directory itself) on Azure App Service run-from-package mount — appears to be a regression in 10.0.9

[samueldjack]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

On an Azure App Service (Windows) app deployed with WEBSITE_RUN_FROM_PACKAGE — where the content root C:\home\site\wwwroot is a read-only mounted zip, not a physical directory — calling Directory.GetFiles(path, searchPattern) against that directory with a search pattern that matches zero files throws:

System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot'.
File name: 'C:\home\site\wwwroot'
   at System.IO.Enumeration.FileSystemEnumerator`1.FindNextEntry()
   at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.IO.Directory.GetFiles(String path, String searchPattern, EnumerationOptions enumerationOptions)
   at System.IO.Directory.GetFiles(String path, String searchPattern)

The exception names the directory as the missing "file". On a normal filesystem the same call returns an empty string[]. The directory exists and is enumerable — a query with a pattern that does match returns results normally; only the zero-match case fails.

This surfaced in production when an app that had been running for weeks began failing to start immediately after the App Service instance was updated to .NET 10.0.9 (the app is framework-dependent and rolls forward to the latest installed patch). Redeploying the identical package with the runtime pinned to 10.0.7 starts cleanly.

Real-world stack trace

The triggering call is a legitimate Directory.GetFiles(appBaseDir, "Ninject.*.dll") inside a third-party library (IronPdf's embedded Ninject module loader), invoked during host startup. Because it throws in an IHostedLifecycleService.StartingAsync, it aborts host startup entirely:

System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot'.
   at System.IO.Enumeration.FileSystemEnumerator`1.FindNextEntry()
   at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.IO.Directory.GetFiles(String path, String searchPattern, EnumerationOptions enumerationOptions)
   at System.IO.Directory.GetFiles(String path, String searchPattern)
   at Ninject.Modules.ModuleLoader...GetFilesMatchingPattern(String path)
   ... (IronPdf license activation) ...
   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellati

Expected Behavior

Calling Directory.GetFiles / Directory.EnumerateFiles on an existing, enumerable directory that contains no entries matching the pattern should return an empty result, as it does on a physical filesystem and as it did on 10.0.7.

Steps To Reproduce

Requires the Azure App Service run-from-package virtual filesystem (the behavior does not reproduce against a normal NTFS directory):

1. Deploy any ASP.NET Core app to a Windows Azure App Service using WEBSITE_RUN_FROM_PACKAGE (zip-mounted, read-only wwwroot).
2. From code running in that process, enumerate the mounted content root with a search pattern that matches nothing:

var dir = AppContext.BaseDirectory;              // C:\home\site\wwwroot (read-only zip mount)
var files = Directory.GetFiles(dir, "NoSuchPattern.*.dll");
// .NET 10.0.7: returns string[0]
// .NET 10.0.9: throws System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot'

The following is a minimal reproduction example. Run pack.ps1 to produce to zip files that should be deployed using runFromZip to an Azure App Service.

rfp-getfiles-regression.zip

Deploying the 10.0.7 zip to AppService will produce the following result when calling Get on the homepage.

{
frameworkDescription: ".NET 10.0.7",
environmentVersion: "10.0.7",
baseDirectory: "C:\home\site\wwwroot\",
websiteRunFromPackage: "1",
machineName: "PD1MDWK001CXZ",
probes: [
    {
        pattern: "__no_such_file__*.dll",
        expected: "empty (string[0])",
        outcome: "returned",
        count: 0,
        exception: null
    },
    {
        pattern: "*.dll",
        expected: "one or more files",
        outcome: "returned",
        count: 1,
        exception: null
    }
]
}

When the 10.0.9 zip is deployed you'll see the output:

{
frameworkDescription: ".NET 10.0.9",
environmentVersion: "10.0.9",
baseDirectory: "C:\home\site\wwwroot\",
websiteRunFromPackage: "1",
machineName: "PD1MDWK001CXZ",
probes: [
  {
    pattern: "__no_such_file__*.dll",
    expected: "empty (string[0])",
    outcome: "THREW",
    count: null,
    exception: "System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot'."
  },
  {
    pattern: "*.dll",
    expected: "one or more files",
    outcome: "returned",
    count: 1,
    exception: null
  }
]
}

Exceptions (if any)

System.IO.FileNotFoundException: Could not find file 'C:\home\site\wwwroot'.
File name: 'C:\home\site\wwwroot'
   at System.IO.Enumeration.FileSystemEnumerator`1.FindNextEntry()
   at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.IO.Directory.GetFiles(String path, String searchPattern, EnumerationOptions enumerationOptions)
   at System.IO.Directory.GetFiles(String path, String searchPattern)

.NET Version

10.0.9

Anything else?

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

Most likely caused by #127974 cc @JeremyKuhne @stephentoub

[jeffhandley]

Thanks for the excellent issue report, @samueldjack. We recognize the disruption this caused you and we're glad you found a workaround by snapping back to the prior servicing version. Your repro details and diagnosis were very helpful here. We are aiming for this to be fixed in the August servicing release.

[jeffhandley]

@samueldjack - FYI I also confirmed your suspicion that this was a regression in 10.0.9. You mentioned pinning to 10.0.7 as a workaround, but I wanted you to know that 10.0.8 would also work.