VSCode allows for special file-system schemes to be registered and used within VSCode for displaying content that may or may not actually be on the local file-system. This is done via the registerFileSystemProvider API.

The GitLens extension leverages this to show remote content and diffs of files:
Here is an example of a URI.
"gitlens://5a429c0/e%3A/repos/osNew/src/clientcore/windows/Core/ntuser/kernel/windows/focusact.cxx?%7B%22path%22%3A%22%2Fe%3A%2Frepos%2FosNew%2Fsrc%2Fclientcore%2Fwindows%2FCore%2Fntuser%2Fkernel%2Fwindows%2Ffocusact.cxx%22%2C%22ref%22%3A%225a429c009a17e1dad822693a5364c0c29ce6c03f%22%2C%22repoPath%22%3A%22e%3A%2Frepos%2FosNew%2Fsrc%22%7D"

Now, that URI is absolutely meaningless to anyone but the GitLens extension 😊

Now, the C/C++ tools extension gets a request to provide custom configuration information for this URI.

This call:
provideCustomConfiguration(docUri, requestFile) {

receives the URI above.

However, somewhere between VSCode sending the URI to C/C++ tools extension and it making it to WAVE's
public async canProvideConfiguration(uri: vscode.Uri, token?: CancellationToken): Promise {

The URI scheme is being "morphed" from "gitlens" to "file" (which is incorrect) with a completely invalid file system path (fspath).

scheme:"file"
fsPath:"e:\REPOS\OSNEW\SRC\CLIENTCORE\WINDOWS\CORE\NTUSER\GITLENS:\5A429C0\E%3A\REPOS\OSNEW\SRC\CLIENTCORE\WINDOWS\CORE\NTUSER\KERNEL\WINDOWS\FOCUSACT.CXX?%7B%22PATH%22%3A%22%2FE%3A%2FREPOS%2FOSNEW%2FSRC%2FCLIENTCORE%2FWINDOWS%2FCORE%2FNTUSER%2FKERNEL%2FWINDOWS%2FFOCUSACT.CXX%22%2C%22REF%22%3A%225A429C009A17E1DAD822693A5364C0C29CE6C03F%22%2C%22REPOPATH%22%3A%22E%3A%2FREPOS%2FOSNEW%2FSRC%22%7D"
If the scheme "were" correctly set, we could filter out registered file system providers and return "false" for request to provide intellisense information.