CEIP uploader crashes on BITS failures (missing file, invalid handle, too many files in job)

[PostSharpAgent]

Symptom

The PostSharp/Metalama telemetry uploader fails while handing a report to BITS. Three distinct COM failures,
all from the same method:

System.Exception: The system cannot find the file specified. (Exception from HRESULT: 0x80070002); error log: No file found.
System.Exception: The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE)); error log:
System.Exception: Exception from HRESULT: 0x80200049; error log:

0x80200049 is BG_E_TOO_MANY_FILES_IN_JOB from the BITS error range.

This is the crash reporter crashing. The reports in this cluster exist only because a second reporting
path caught the failure of the first, so every occurrence of this defect is, by construction, also a
telemetry report that did not get uploaded. The true rate is higher than what is measured here, and there is
no way from inside this data to say by how much.

Where it happens

UploadManager.Upload builds a BITS job and adds files to it, from two different hosts: the CLI
(ProgramCli.UploadAsync, during maintenance) and the UI's own problem reporter
(ProgramUi.ReportProblem).

System.Exception: The system cannot find the file specified. (Exception from HRESULT: 0x80070002); error log: No file found.
    PostSharp.Settings.PostSharpIL.Ceip.UploadManager.Upload()
    PostSharp.Settings.PostSharpIL.Ceip.UploadManager.PerformMaintenance()
    PostSharp.Settings.ProgramCli.<UploadAsync>d__5.MoveNext()
    PostSharp.Settings.ProgramCli.<MainCoreAsync>d__3.MoveNext()

   ---> System.Runtime.InteropServices.COMException: The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))
      PostSharp.Settings.PostSharpIL.Ceip.Bits.IBackgroundCopyJob.AddFile(String remoteUrl, String localName)

   ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80200049
      PostSharp.Settings.PostSharpIL.Ceip.Bits.BackgroundCopyManagerClass.CreateJob(String displayName, BG_JOB_TYPE type, GUID& pJobId, IBackgroundCopyJob& ppJob)

Each failure has a different meaning and none of them is handled:

HRESULT	Meaning	Where
0x80070002	The file to upload is not there	Upload
0x80070006	Invalid handle	IBackgroundCopyJob.AddFile
0x80200049	BG_E_TOO_MANY_FILES_IN_JOB	BackgroundCopyManagerClass.CreateJob

0x80070002 is the largest by volume, and is the benign one: a queued report file was removed (by cleanup,
by the user, by an antivirus) between being enumerated and being uploaded. That is an ordinary race, not an
error condition, and it should not produce a crash report.

0x80200049 is the interesting one. BITS limits files per job, so this says the pending-report queue has
grown past that limit. That in turn suggests uploads have been failing for a while on those machines and
nothing drains the backlog, which would make this defect self-sustaining.

Scale

Reported by 47 distinct installations across 6 crash signatures, producing 82 reports, over the
retained window (three months).

Lineage	First version	Last version
2026.0	2026.0.3.0	2026.0.12.0
2025.1	2025.1.2.0	2025.1.14.0
2025.0	2025.0.6.0	2025.0.6.0
2024.1	2024.1.4.0	2024.1.6.0
2024.0	2024.0.5.0	2024.0.6.0
2023.0	2023.0.3.0	2023.0.8.0
6.11	6.11.2.0	6.11.2.0
6.10	6.10.7.0	6.10.23.0
6.9	6.9.8.0	6.9.11.0
6.8	6.8.9.0	6.8.7.0
6.7	6.7.10.0	6.7.11.0

Long-standing across eleven lineages, the earliest observation reaching back to PostSharp 6.7 and the
most recent report dated 2026-07-27. Do not bisect for it.

Suggested action

• Handle 0x80070002 silently. A report file that vanished before upload is not an error worth
  reporting, and reporting it costs a second upload.
• Batch the job when the queue is large, so BG_E_TOO_MANY_FILES_IN_JOB cannot happen, and cap or age
  out the pending-report directory so a backlog cannot grow without bound.
• Do not report a telemetry failure through telemetry, or at least not through the same queue that is
  failing. As it stands the failure path feeds the thing that failed.

---

Filed from CEIP crash reports. 6 invariant problems; ids are recorded against this candidate in the triage
database. Figures cover the retained window (three months) and count distinct reporting installations.