The dreaded "application configuration is incorrect" error | Hacker News Reader

The dreaded "application configuration is incorrect" error

virtualdub.org

12 pointsskorks9 comments

This used to bite me all the time before I switched to using Python when distributing Windows builds of stuff. I figured it out in an ad-hoc way, but with this article I actually understand it.

Definitely one of the least helpful error messages of all time.

It's a shame that more technologies aren't moving toward a "compile and statically link everything" model, there's a lot to be said for that model in certain circumstances.

Yeah, it is bizarre how bad Microsoft error messages can be. I can just conceive designing a system that works this way, but I have absolutely no idea how someone would design such a system and have it produce absolutely no useful diagnostic message anywhere when it goes wrong.

This is pretty much the worst case scenario in the fight between maintaining nice, human readable error messages for unsophisticated users and ugly, information dense technical error messages for aiding debugging for technical users (and developers). The result here is a message that helps neither users nor developers understand what went wrong or how to fix it. A message such as "fault in module Foo @ address 0x921851" or somesuch would be no more incomprehensible to the average user than this and a message such as "something went wrong, oh noes!" would be no more useless to developers. As it stands it's only through the magic of the internet and the fact that, thankfully, this message is at least a little unique that people are able to find out what this message really means and how to fix it.

My first experience with COM involved a week of staring at a dialog box saying "Error -1" and twisting knobs in my code until the error dialog went away.

This was from a piece of COM that was entirely procedural, no UI at all. Yet someone had had the bright idea of (a) indicating an error with a dialog box instead of a return value, which brought the entire synchronous call to a screeching halt, and (b) reporting an absolutely useless error value.

It would have been more useful had the COM code in question /crashed/ -- at least I could have debugged it.

It's not just Microsoft, I've seen this "error -1" behavior in many APIs, on many systems. I've seen code that reported /any/ error as being "out of memory" (trying to blame it on someone else? I've never understood that one, if it's not just being lazy).

Detailed error reporting is as much of an art as designing the working face of an API. The problem is, if you flub it, you're trying to mollify and calm an already irritated user. Think of errors as the first line in customer support, and get them right.

So, why would you want to use the CRT as a DLL? The article doesn't make that clear.

One reason would be to reduce executable size on systems where you are sure the correct DLL exists. This made a lot of sense when executable sizes were critical. Install the CRT once, and any app can use it. The MS approved solution as I understand it is to bundle the CRT installer in your own installer. This of course makes no sense if you have no installer. So it's a better idea to statically link the CRT and not worry about what your users have.

It enables someone else (a system administrator, microsoft patch, etc.) to redirect it to a new version without your intervention if a security issue is identified in the version you have shipped with your application. It's actually a very sophisticated system that allows any number of versions of the same dll to be used simultaneously within the system. It is also a nightmare for unsuspecting developers when it goes wrong.

I've never seen a sysadmin do that, they just nuke the offending app. So I'm filing it as "science fiction". Don't worry, use /MT.

Reply on news.ycombinator.com