LoadLibrary error
PaulH
LoadLibrary command. (I'm using multi-byte, so it translates to
LoadLibraryA(), if that matters.)
On my development PC (VS2005) and another PC with VS2008 on it, this
program works great. When I move it to a different PC with no dev
environment, the LoadLibrary() call fails and GetLastError() returns
the code: 0x000036B1 "This application has failed to start because the
application configuration is incorrect. Reinstalling the application
may fix this problem. "
I've tried using debug versions and release versions of the code, both
yield the same result. The DLL file and the executable are in the same
directory.
Can anybody offer a suggestion as to what may be going wrong?
Thanks,
PaulH
If it helps, the exact code looks like this:
typedef std::basic_string< TCHAR, std::char_traits< TCHAR >,
std::allocator< TCHAR > > tstring;
const tstring& DriverDll = _T( "mydriver.dll" );
_hDriver = LoadLibrary( DriverDll.c_str() );
if( !_hDriver )
{
ATLTRACE( _T( "RST::Unable to locate driver: %s. Err:
%#08x.\n" ),
DriverDll.c_str(),
GetLastError() );
return FALSE;
}
Nathan Mates
PaulH <paul...@gmail.com> wrote:
>On my development PC (VS2005) and another PC with VS2008 on it, this
>program works great. When I move it to a different PC with no dev
>environment, the LoadLibrary() call fails and GetLastError() returns
>the code: 0x000036B1 "This application has failed to start because
>the application configuration is incorrect. Reinstalling the
>application may fix this problem. "
Welcome to ManifestHell(tm). This is because Microsoft has pushed
out a half-baked technology out on the public well before it's really
ready for primetime. Rather than any sort of useful information in a
dialog box, you're left wondering until you hear from other programmers.
Solutions:
1) Compile your app/dll with the static C runtime environment (i.e.
not the DLL form), and turn off all manifest items in the linker and
manifest file options.
2) Bloat up your installed by several megs, and force end users to
install this:
VC2005+SP1 : http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
3) Hope that MS tests their products out in real-world situations
before foisting anything like manifests on us again. But, as long as
MS has a mentality of "we'll get it right, eventually" they'll force
lots of people to use their half-baked implementations.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
PaulH
> In article <1190241321.038415.3...@r29g2000hsg.googlegroups.com>,
>
> PaulH <paul.h...@gmail.com> wrote:
> >On my development PC (VS2005) and another PC with VS2008 on it, this
> >program works great. When I move it to a different PC with no dev
> >environment, the LoadLibrary() call fails and GetLastError() returns
> >the code: 0x000036B1 "This application has failed to start because
> >the application configuration is incorrect. Reinstalling the
> >application may fix this problem. "
>
> Welcome to ManifestHell(tm). This is because Microsoft has pushed
> out a half-baked technology out on the public well before it's really
> ready for primetime. Rather than any sort of useful information in a
> dialog box, you're left wondering until you hear from other programmers.
>
> Solutions:
>
> 1) Compile your app/dll with the static C runtime environment (i.e.
> not the DLL form), and turn off all manifest items in the linker and
> manifest file options.
>
> 2) Bloat up your installed by several megs, and force end users to
> install this:
>
>
> VC2005 :http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F...
>
> 3) Hope that MS tests their products out in real-world situations
> before foisting anything like manifests on us again. But, as long as
> MS has a mentality of "we'll get it right, eventually" they'll force
> lots of people to use their half-baked implementations.
>
> Nathan Mates
> --
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/
> # NOT speaking for Pandemic Studios. "Care not what the neighbors
> # think. What are the facts, and to how many decimal places?" -R.A. Heinlein
What is the compiler option to use the static C runtime environment?
SvenC
>>On my development PC (VS2005) and another PC with VS2008 on it, this
>>program works great. When I move it to a different PC with no dev
>>environment, the LoadLibrary() call fails and GetLastError() returns
>>the code: 0x000036B1 "This application has failed to start because
>>the application configuration is incorrect. Reinstalling the
>>application may fix this problem. "
>
> Welcome to ManifestHell(tm). This is because Microsoft has pushed
> out a half-baked technology out on the public well before it's really
> ready for primetime. Rather than any sort of useful information in a
> dialog box, you're left wondering until you hear from other programmers.
Come on, the side-by-side technology works and it is quite easy to get it
right. So calling it half-baked technology is a bit harsh. Maybe you could
provide some details what is half-baked and how you would have done it
better.
You provided solutions which are absolutely easy to follow and I would add
the usage of the merge modules in case you provide an installer package
which is quite typical for most applications which consist of more than one
executable.
So to me this is just a new technologie we developers have to understand and
use then our customers have no pain.
--
SvenC
PaulH
> In article <1190241321.038415.3...@r29g2000hsg.googlegroups.com>,
>
> >On my development PC (VS2005) and another PC with VS2008 on it, this
> >program works great. When I move it to a different PC with no dev
> >environment, the LoadLibrary() call fails and GetLastError() returns
> >the code: 0x000036B1 "This application has failed to start because
> >the application configuration is incorrect. Reinstalling the
> >application may fix this problem. "
>
> Welcome to ManifestHell(tm). This is because Microsoft has pushed
> out a half-baked technology out on the public well before it's really
> ready for primetime. Rather than any sort of useful information in a
> dialog box, you're left wondering until you hear from other programmers.
>
> Solutions:
>
> 1) Compile your app/dll with the static C runtime environment (i.e.
> not the DLL form), and turn off all manifest items in the linker and
> manifest file options.
>
> 2) Bloat up your installed by several megs, and force end users to
> install this:
>
>
> VC2005 :http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F...
>
> 3) Hope that MS tests their products out in real-world situations
> before foisting anything like manifests on us again. But, as long as
> MS has a mentality of "we'll get it right, eventually" they'll force
> lots of people to use their half-baked implementations.
>
> Nathan Mates
> --
> # Programmer at Pandemic Studios --http://www.pandemicstudios.com/
> # NOT speaking for Pandemic Studios. "Care not what the neighbors
> # think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Installing the VC redistributables fixed the problem. I would never
have guessed that a loadlibrary() failure could be attributed to
missing the VCredist. Go figure.
Thanks for your help.
Nathan Mates
PaulH <paul...@gmail.com> wrote:
>> 1) Compile your app/dll with the static C runtime environment (i.e.
>> not the DLL form), and turn off all manifest items in the linker and
>> manifest file options.
>What is the compiler option to use the static C runtime environment?
Right click on all project(s), select properties -> C/C++ -> Code
Generation -> Runtime Library. Use either "Multi-threaded" (for
release builds) or "Multi-threaded Debug" (for debug builds). While
you're there, go to Linker (for exe/dlls), and go to Linker -> Manifest
File -> Generate Manifest: No. And, finally, go to Manifest Tool ->
Input and Ouptput -> Embed Manifest: No.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
Nathan Mates
SvenC <sv...@community.nospam> wrote:
>> Welcome to ManifestHell(tm). This is because Microsoft has pushed
>> out a half-baked technology out on the public well before it's really
>> ready for primetime. Rather than any sort of useful information in a
>> dialog box, you're left wondering until you hear from other programmers.
>Come on, the side-by-side technology works and it is quite easy to
>get it right. So calling it half-baked technology is a bit
>harsh. Maybe you could provide some details what is half-baked and
>how you would have done it better.
My #1 gripe can be summarized in three words: *USELESS* *ERROR*
*MESSAGES*. Saying "The application parameter is incorrect" when you
try to launch something w/o all the DLLs installed is
use-fracking-less. Error messages, when necessary, need to have some
sort of helpful information in them. Even the most minimal things like
(1) which DLLs it's looking for, or better yet, (2) optional URL that
end users can click on to get a download of the DLL packages would
help a lot, and reduce questions like this every other week in these
newsgroups.
My #2 gripe is that that this is a problem that only shows up when
you try and give this to end users. You can use the Application
Verifier to make sure things are all happy on your machine, but the
first time you pass things around, you're going to be bitten. Not
everyone wants to use a installer, especially the first few times you
pass things around. At work, we check the latest versions of inhouse
tools into perforce (== version control), so that people can fetch new
builds along with everything else. There's no installers involved.
So, educating everyone that they need to run things when they get a
useless message is a pain. Manifests and side-by-side things seem
designed to be used in *only* one specific way. As soon as you deviate
from that, you're in trouble. That's why I call it half-baked -- if
something is to be used by *everyone*, it's got to be general and
robust. It ain't.
Nathan Mates
PaulH <paul...@gmail.com> wrote:
>Installing the VC redistributables fixed the problem. I would never
>have guessed that a loadlibrary() failure could be attributed to
>missing the VCredist. Go figure.
That's the primary reason why I call the current implementation of
manifests half-baked -- when they fail, they fail with *no* *useful*
*information*. That's not a robust solution for real world use.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
Ben Voigt [C++ MVP]
"Nathan Mates" <nat...@visi.com> wrote in message
news:13f58qo...@corp.supernews.com...
> In article <1190305597.0...@g4g2000hsf.googlegroups.com>,
> PaulH <paul...@gmail.com> wrote:
>>Installing the VC redistributables fixed the problem. I would never
>>have guessed that a loadlibrary() failure could be attributed to
>>missing the VCredist. Go figure.
>
> That's the primary reason why I call the current implementation of
> manifests half-baked -- when they fail, they fail with *no* *useful*
> *information*. That's not a robust solution for real world use.
That's actually true of DLL dependencies in general, not only manifests.
There's no reason in the world the message couldn't say "yourlib.dll failed
to load because msvcrt80.dll could not be found."
Nathan Mates
Ben Voigt [C++ MVP] <r...@nospam.nospam> wrote:
>> That's the primary reason why I call the current implementation of
>> manifests half-baked -- when they fail, they fail with *no* *useful*
>> *information*. That's not a robust solution for real world use.
>That's actually true of DLL dependencies in general, not only
>manifests. There's no reason in the world the message couldn't say
>"yourlib.dll failed to load because msvcrt80.dll could not be
>found."
Regular DLL dependencies at least report *what* it wants, but
manifests are less useful -- they report nothing to the consumer
pointing out the actual problem. If, as you claim, manifests could
report the missing DLL, why doesn't it? Actual error handling, useful
reporting is the last things that tend to get added to a system,
because it's seen as grunt work. But, it's required to really move
from the "half-baked" to the "actually usable" stage.
Mark Salsbery [MVP]
I agree the error message is useless.
I'm pretty sure the message used to state which DLL was missing - maybe
older OSs still do.
Knowing the missing DLL name is useless too IMO. Sure, it is/was useful to
us during development...
The consumer shouldn't ever see the message.
Proper deployment is our responsibility, not the end-user's. That's
probably why there's way too much documentation on the subject:
http://msdn2.microsoft.com/en-us/library/zebw5zk9(VS.80).aspx
Cheers,
Mark
--
Mark Salsbery
Microsoft MVP - Visual C++
"Nathan Mates" <nat...@visi.com> wrote in message
news:13f5qa7...@corp.supernews.com...
Tim Roberts
>
>Come on, the side-by-side technology works and it is quite easy to get it
>right.
I disagree completely and vehemently. SxS is an overengineered, opaque,
complicated, and confusing solution to a problem that has been adequately
solved for at least a decade. It's astounding to me that Microsoft was the
only player who did not seem to realize this.
>So calling it half-baked technology is a bit harsh. Maybe you could
>provide some details what is half-baked and how you would have done it
>better.
How would I have done it better? By not changing anything. By continuing
to do things they way they had been done in the recent past. By
establishing and following the reasonable rules for versioning that
application vendors had been following until VS2005.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
SvenC
>>provide some details what is half-baked and how you would have done it
>>better.
>
> How would I have done it better? By not changing anything. By continuing
> to do things they way they had been done in the recent past. By
> establishing and following the reasonable rules for versioning that
> application vendors had been following until VS2005.
The term "dll hell" existed way before SxS so it seems to me that not
everything was so wonderful and easy and working. The mind is weak and tends
to forget bad old things and glorify others which may not deserve it.
How many people got it wrong and placed their dlls into system32 or added
their directory to PATH so that enough ways for dll collision existed. So
SxS IMHO is a way to get coexisting versions of system modules installed on
one machine and bind the executables to the correct version they need.
--
SvenC
SvenC
>>Come on, the side-by-side technology works and it is quite easy to
>>get it right. So calling it half-baked technology is a bit
>>harsh. Maybe you could provide some details what is half-baked and
>>how you would have done it better.
>
> My #1 gripe can be summarized in three words: *USELESS* *ERROR*
> *MESSAGES*. Saying "The application parameter is incorrect" when you
> try to launch something w/o all the DLLs installed is
> use-fracking-less. Error messages, when necessary, need to have some
> sort of helpful information in them. Even the most minimal things like
> (1) which DLLs it's looking for, or better yet, (2) optional URL that
> end users can click on to get a download of the DLL packages would
> help a lot, and reduce questions like this every other week in these
> newsgroups.
I am with you on this one. The error message could be way better. But still:
would your end users know what to do, when the see "The C++ runtime is
missing. Please install xxx."? If I was your customer I would ask myself why
the vendor was not able to provide me a working setup routine and if he ever
tested his application.
--
SvenC
Nathan Mates
Mark Salsbery [MVP] <MarkSalsbery[MVP]@newsgroup.nospam> wrote:
>Knowing the missing DLL name is useless too IMO. Sure, it is/was
>useful to us during development...
Well, during development, if someone copies an exe to another box,
it sure helps to figure out what went wrong. Having a DLL name means
that you can always google that, and maybe find things later. The
manifest's "message" is a total step backwards -- being able to have a
(customizable) message, that for MS DLLs, would say "Get
vcredist_x86.exe from http://..." (and some other message for DLLs
made by some other party) would be a proper step forwards.
>Proper deployment is our responsibility, not the end-user's. That's
>probably why there's way too much documentation on the subject:
>http://msdn2.microsoft.com/en-us/library/zebw5zk9(VS.80).aspx
I'm sorry, but I disagree 100% with the mentality that produced a
massive tome on "how to deploy what you just built." It is a sign of
institutional arrogance and outright stupidity on the side of
Microsoft to have allowed such a thing to come into existance. The
deployment "directions" for HelloWorld.exe should not be any longer
than the source code that produced it. Period. But, as of VS2005,
this principle has been violated.
Before VS2005, one could simply compile up HelloWorld.exe, and do
the *natural* deployment to another computer -- put on a network
share/USB stick/whatever, and just run it. That *worked*. Now, if
someone builds the same bit of source code, they've suddenly got to
read and understand a metric boatload of confusing directions from MS
simply to run their simple app on another computer that's never had VS
installed on it. I've said it before, I'll repeat it: THIS IS WRONG. I
don't care if it's the "MS way." People are used to *easy* deployment
by copying, not going thru some complicated installer. MS does every
beginning developer a *grave* disservice by making them jump thru 17
hoops in order to share their creations.
Nathan Mates
SvenC <sv...@community.nospam> wrote:
>> My #1 gripe can be summarized in three words: *USELESS* *ERROR*
>> *MESSAGES*. Saying "The application parameter is incorrect" when you
>> try to launch something w/o all the DLLs installed is
>> use-fracking-less. Error messages, when necessary, need to have some
>> sort of helpful information in them. Even the most minimal things like
>> (1) which DLLs it's looking for, or better yet, (2) optional URL that
>> end users can click on to get a download of the DLL packages would
>> help a lot, and reduce questions like this every other week in these
>> newsgroups.
>I am with you on this one. The error message could be way
>better. But still: would your end users know what to do, when the
>see "The C++ runtime is missing. Please install xxx."? If I was your
>customer I would ask myself why the vendor was not able to provide
>me a working setup routine and if he ever tested his application.
I'd fire this use case right back at you: what if the 'vendor' is
that 'end user'? When someone is testing out copying things around for
the first time, and the app fails, shouldn't the error messages be
*better*? Saying "the application parameter is incorrect" tells the
person nothing. It doesn't teach them *how* to fix the problem. Heck,
it barely gives them anything useful to google. That useless error
message doesn't give people any pointers to the new rules (as of
VS2005) that you have to jump thru 17 hoops to get something deployed
on a new machine. An error message produced by a mature product is
educational. Manifests are nowhere near that.
Useful error messages are looked down on by a lot of junior
developers, simply because it's a lot of grunt work. Software without
such useful error messages falls into the category of "half-baked,"
simply because it was pushed out the door w/o serious consideration of
the end users. And for manifests, the end users are the people running
VS2005. Period.
Tim Roberts
>
>The term "dll hell" existed way before SxS so it seems to me that not
>everything was so wonderful and easy and working. The mind is weak and tends
>to forget bad old things and glorify others which may not deserve it.
>
>How many people got it wrong and placed their dlls into system32 or added
>their directory to PATH so that enough ways for dll collision existed.
Yes. In 1993, "DLL hell" was a real problem, and Microsoft was one of the
worst offenders. They themselves released a newer version of one of the
common control DLLs with a version number less than the one it was to
replace.
However, disasters like that helped us all learn the right way to handle
that. Install our private DLLs in our private directories. Be absolutely
strict about version numbers. Never replace a DLL with an older one. Never
release an updated DLL that is not compatible with old versions. Anyone
with a brain has been following those rules for 10 years, and because of
that "DLL hell" is now just a distant memory. It is a solved problem.
>So SxS IMHO is a way to get coexisting versions of system modules installed
>on one machine and bind the executables to the correct version they need.
There should not NEED to be "coexisting versions of system modules". If
they need to fix an old version, or add new functionality, then REPLACE the
old file.
No, SxS is baroquely complicated and entirely unnecessary. It solves a
problem that did not need to be solved, and complicated things that used to
be simple.
Tim Roberts
>
> I'm sorry, but I disagree 100% with the mentality that produced a
>massive tome on "how to deploy what you just built." It is a sign of
>institutional arrogance and outright stupidity on the side of
>Microsoft to have allowed such a thing to come into existance. The
>deployment "directions" for HelloWorld.exe should not be any longer
>than the source code that produced it. Period. But, as of VS2005,
>this principle has been violated.
>
> Before VS2005, one could simply compile up HelloWorld.exe, and do
>the *natural* deployment to another computer -- put on a network
>share/USB stick/whatever, and just run it. That *worked*. Now, if
>someone builds the same bit of source code, they've suddenly got to
>read and understand a metric boatload of confusing directions from MS
>simply to run their simple app on another computer that's never had VS
>installed on it. I've said it before, I'll repeat it: THIS IS WRONG. I
>don't care if it's the "MS way." People are used to *easy* deployment
>by copying, not going thru some complicated installer. MS does every
>beginning developer a *grave* disservice by making them jump thru 17
>hoops in order to share their creations.
It's bad form to post a "me too" posting, but I want to go on record as
agreeing with you 100%.