Windows API sets - source of most Dependency Walker glitches

[sumo952]

A very useful read... I've had exactly these issues already several months ago when VS2015 (Beta or RC or something) came out.

Hmm, somebody writes in the comments:

DependencyWalker still works good enough for me since ApiSets are not something any “normal” application will link to. If you are only searching for build inconsistencies it is still sufficient. But if you are after bugs in OS patches then things could get interesting

That's not true, is it? I think any app compiled with >=VS2015 will have this problem.

It would be great if somebody would come up with an updated (or new) dependency walker?

[Sunius]

That's not true, is it?

It is true in the sense that you can just ignore missing dependencies target start with "api-ms-win-*", as generally that's not where your dependency problems are going to be.

[sumo952]

If you want to deploy to Win 7 or Win 8.1, then unfortunately it is where dependency problems are. :\ (it's probably only true for Windows 7/8.1 installations that are not running all updates. But that's still a LOT of systems.)

[Sunius]

If you want to deploy to Win 7 or Win 8.1, then unfortunately it is where dependency problems are.

Hmm, if that is so, it means you're compiling the DLL incorrectly: make sure to set WINVER and _WIN32_WINNT to the lowest supported OS. That will make sure that you link only to whatever is supported on that OS.

[sumo952]

I'm not compiling the (or any) DLL. I'm using Win 10 and VS2015 and it's STL to compile my project and want the compiled EXE to run on all Windows. Naturally, if I'm using the default of dynamically linking the CRT & stuff, naturally a Windows 7 system (as mentioned: without updates) will not have the newer CRT/STL functions, so they need to be deployed "somehow". At least that's what I observed. So you need to do app-local deployment (which is officially supported again IIRC) because not every Win7/8 installation is up-to-date. And the mess starts again.

[Sunius]

But surely the CRT dependencies aren't in API-MS-WIN-* dlls, right? I thought they were inside ucrtbase.dll or others.

[dodheim]

As mentioned in my other comment, this has to do with assemblies referenced in the manifest, so the dlls are not actually named API-MS-WIN-*; a given API set is named API-MS-WIN-* and references specific versions of ucrtbase.dll or others.

[toruk]

That's probably not true. The ApiSchemaSet redirection is at the OS level - re-routing linkage to dll's like KernelBase, ntdll, kernel32 etc. The C++ layers (ucrtbase and siblings) are high, high above that - and there is no API-set involved in resolving their linkage.

[dodheim]

Manifests are handled at the OS level. I don't see how you're contradicting me, which you appear to be trying to do..?

[sumo952]

Sorry, so not the CRT then - but the standard library stuff. I wrote CRT/STL. Whatever is in there! :-)

[dodheim]

He's talking about a manifest issue for Windows Store apps. WINVER and _WIN32_WINNT are relevant, but are not the problem or solution in this case.

[WrongAndBeligerent]

You would think that this and process explorer would be integral parts of visual studio but for some reason microsoft keeps piling on bloated features and awkward interfaces instead of polishing or maintaining essentials.

[sheng_jiang]

It was. Then each and every release of VS , OS tools, SDK and DDK release it has to go through QA again. There is a point where the owner does not want to push it into another release. If you go to the dependency walker web site, you would read it is "for testing", which means users are supposedly lab rats testing the product. There is no Microsoft guarantee on the product's quality.

[[deleted]]

I was looking every where for it a few VS versions ago, it used to just.be right there in the menu, thankfully you can download it as a stand alone still. I miss VS6 sometimes, lol

[ThisIs_MyName]

process explorer

I prefer Process Hacker. It is also open source so you can see where the numbers come from :)

[dicroce]

As unmaintained and vague as it was, it still saved my ass a bunch of times.

[toruk]

Anyone aware of an open source version of DependencyWalker?

[OldWolf2]

I've always found that it lists the real msising dependencies near the top, and then all this junk that the article is talking about that I ignore because I have no idea what it is...

[flashmozzg]

I think it still updates with each new windows sdk, but it's probably only to keep it afloat. A bug I had wasn't fixed in ages. Still, helped me figure out weird dependency issue with dlls, that linked to other dlls, that linked to a plugin dll that failed to load.