Conversation
Chuccle
force-pushed
the
chore/codeql-pack-1.10.0
branch
2 times, most recently
from
August 23, 2026 02:25
42576d7 to
a99159b
Compare
CodeQL has been failing every scheduled run on master with error C1041: cannot open program database ... if multiple CL.EXE write to the same .PDB file. Two independent causes, and fixing only the first leaves it red. Across projects: all seven sandbox targets defaulted IntDir to $(Platform)\$(Configuration)\ beside the project, so their object files and one shared vc*.pdb landed in the same folder. MSBuild has been saying so on every build as MSB8028, "can lead to incorrect clean and rebuild behavior". Each target now gets its own directory. Within a project: every sandbox target mixes C and C++ sources, and MSBuild compiles the two groups in separate CL.EXE invocations because their command lines differ. Both write the project PDB, so they race and one loses -- the same error, one level down. /FS is what the error message itself prescribes. Why it looked intermittent, and why nobody saw it locally: the second race needs two language groups compiling at once, which normally only happens on a full rebuild, and build.yml plus Invoke-BlorgChecks.ps1 both build serially. codeql.yml is the only thing passing /m. So a warm incremental tree stayed green while CI and any fresh checkout failed. Verified in a throwaway worktree, which is the condition that reproduces it -- a full rebuild with nothing cached. Before: exit -1, C1041. After, both the Build tier and the exact CI command (msbuild BlorgFS.sln /p:Configuration=Release /p:Platform=x64 /m) exit 0 with zero C1041 and zero MSB8028. Not a consequence of the query-pack bump. It predates it; that bump's pull request is simply the first thing that ever ran the workflow.
The workflow is schedule-only, and scheduled workflows run only on the default branch. So the one change that decides what CodeQL reports -- a query-pack pin in .github/codeql/codeql-config.yml -- could only ever be merged unrun, with the first evidence that it builds, resolves and reports arriving the following Saturday, on master. Two triggers fix that. A pull request touching this workflow or .github/codeql/ runs the analysis it is changing, which is precisely when a run is worth paying for. workflow_dispatch covers re-scans on demand -- after a pack bump, or after a batch of fixes -- instead of a seven-day wait. Neither makes CodeQL a per-push gate. PREfast already runs on every build.yml push and PR, which is why this was weekly to begin with. README gains a CI section, since when each of the three workflows runs, and why they are split that way, was previously only discoverable by reading three YAML files.
Pinned at 1.1.0 and well behind. Pinning itself is right -- a pack release must not silently change what a scheduled scan reports -- but a pin still has to be reviewed rather than frozen, and this is the pack carrying the driver-specific IRQL and annotation queries, so a stale one is lost coverage on exactly the class of bug hardest to find any other way. Ordered after the trigger change on purpose: with it in place, the pull request carrying this bump runs the analysis under the new pack rather than merging it unverified. The previous triage (0 IRQL findings, 31 own-code hits all dismissed as false positives with reasons) will need redoing against the new queries rather than assuming those verdicts still hold.
Chuccle
force-pushed
the
chore/codeql-pack-1.10.0
branch
from
August 23, 2026 02:42
a99159b to
fa1ce1a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pinned at 1.1.0 and well behind. Pinning itself is right -- a pack release must not silently change what a scheduled scan reports -- but a pin still has to be reviewed rather than frozen, and this is the pack carrying the driver-specific IRQL and annotation queries, so a stale one is lost coverage on exactly the class of bug hardest to find any other way.
The previous triage (0 IRQL findings, 31 own-code hits all dismissed as false positives with reasons) will need redoing against the new queries rather than assuming those verdicts still hold.