bizarre asp.net app loading failure

[=?Utf-8?B?TWFyaw==?=]

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

[=?Utf-8?B?TWFyaw==?=]

Thanks Bruce... We'll give that a try. Hopefully that will turn something up.

By the by, when do native DllImports() get resolved? When the assembly is
loaded or when some code path need it?

By the other by, I ran into something apparently a number of people have -
running dumpbin.exe doesn't work initially; it needs msvcp80.dll. But if you
copy msvcp80.dll from one of the other VS8 directories into VC\bin,
dumpbin.exe will run but basically everything else craps out after that (IIS
crashes, VS won't build anything, etc). What's up with that?

Thanks
Mark

"bruce barker" wrote:

when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

[=?Utf-8?B?TWFyaw==?=]

Hi Bruce...

Well, I gave it a try but unfortunately the fusion logs didn't show
anything. I see a bunch of assembly load logs for application 3e70de80
(presumably the name for the app pool). The fusion log for
dtSearchNetApi2.dll says the load was successful; all the assembly loads show
as successful. But then the web page itself blows up saying that
dtSearchNetApi2.dll failed to load.

The test page doesn't reference the assembly at all, so there's not any code
being exercised.

I've never had much luck with Fusion logs; haven't found any useful
information in them.

I did try swapping a bunch of other assemblies in and out of the \bin
directory. It's definitely the dtSearchNetApi2.dll that IIS isn't liking,
but no clue as to why.

Not sure where to look from here.

Thanks
Mark

"bruce barker" wrote:

when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

[=?Utf-8?B?TWFyaw==?=]

PS - I'm guessing that Depends is not side-by-side component aware, is that
true? On machines where it's working and the one where it's not, a number of
the native dependencies (msvcp80.dll for example) only exists under winsxs.

Presumably the binding is getting served from there, but Depends doesn't
seem to see those when it's reporting missing dlls...

Thanks
Mark
"bruce barker" wrote:

when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

[Steven Cheng [MSFT]]

Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>From: =?Utf-8?B?TWFyaw==?= <mm******@nospam.nospam>
References: <C6**********************************@microsoft.co m>

<B1**********************************@microsoft.co m>

>Subject: RE: bizarre asp.net app loading failure
Date: Wed, 11 Jun 2008 14:46:01 -0700

>
PS - I'm guessing that Depends is not side-by-side component aware, is

that

>true? On machines where it's working and the one where it's not, a number

of

>the native dependencies (msvcp80.dll for example) only exists under winsxs.

Presumably the binding is getting served from there, but Depends doesn't
seem to see those when it's reporting missing dlls...

Thanks
Mark
"bruce barker" wrote:

>when an asp.net application starts, all dll's in the bin folder are

loaded.

>most dll's have build references, so this dll's must be loaded. asp.net

is

>different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:

We've got a wierd failure happening on just one machine. One part of

our

product uses a 3rd party search implementation (dtSearch). DtSearch

has a

native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a

couple

of assemblies that reference it, even though they are not used by all

the

applications.

Recently we got an update for dtSearch, which a developer checked in.

For

some reason I can't figure out, it cause the application as deployed

by the

msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly

'dtSearchNetApi2,

Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one

of its

dependencies. This application has failed to start because the

application

configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same

ASP.Net

application bin directory as dtSearchNetApi2.dll, even though our

referencing

assemblies are not used by the app. The 1.0.3056.39769 version is the

new

copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old

versions

of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I

said,

due to odd packaging the native dten600.dll has never been included

but the

old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for

new

and old dtSearch. The machine in question has never had the msvc?80

dlls,

but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the

missing

late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use

it) or

why it's just now complaining about not finding some dependencies

where it

didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them

or not?

Any tips at what I should look at next to figure out why it just

started

happening and only on this one machine?

Thanks
Mark

[=?Utf-8?B?TWFyaw==?=]

Thanks, Steven...

I'm not that familiar with how things are resolved into the winsxs
hierarchy. I understand it's kind of like the GAC for unmanaged code and
that multiple versions of a dll may be in there, but when the loader is
resolving a dll reference, is it now paying attention to the version linked
to? I'm used to the old dll hell where it picks up the first one it stumbles
over.

One of the things I noticed on this box that's not working is that it
doesn't have a lot of the newer versions of the msvc?80.dlls on it that the
other boxes do. I was wondering if the winsxs system was somehow resolving
versions too, that it might be a mismatch there as well.

The dtSearch unmanaged dll is not present on some machines where IIS is
working, so the only other unmanaged references I could think where having
problems would be the msvc?80.dlls.

Thanks
Mark
"Steven Cheng [MSFT]" wrote:

Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx

[=?Utf-8?B?TWFyaw==?=]

Hi Steven, Bruce...

Figured it out eventually. The problem was that the 3rdparty component was
dependent on newer versions of the CRT than we had on the machine. I wasn't
familiar with the winsxs pre-emption of the path search, so attempts to put
newer versions of dlls in the deploy directory weren't working.

I found a newer vcredist, installed it, and the problem went away.

thanks
Mark
"Steven Cheng [MSFT]" wrote:

Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

[Steven Cheng [MSFT]]

Thanks for your followup Mark,

I'm glad that you've figured out the issue. So after installing the newer
version of the vc runtime, the side by side system is able to find the
expected version.

BTW, yes, currently windows OS is adding more support for unmanaged dll to
leverage side by side deployment so as to avoid dll hell. And for the
latest visual studio, its unmanaged C++ project will also generate binary
output that add such support(different from old version's outputs). Here
are some articles which may also be helpful:

#Side-by-side Assemblies
http://msdn.microsoft.com/en-us/library/aa376307.aspx

#Why does VC8 install libraries to WinSxS?
http://blogs.msdn.com/martynl/archiv...13/480880.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>Subject: RE: bizarre asp.net app loading failure
Date: Thu, 12 Jun 2008 08:20:00 -0700

>
Hi Steven, Bruce...

Figured it out eventually. The problem was that the 3rdparty component

was

>dependent on newer versions of the CRT than we had on the machine. I

wasn't

>familiar with the winsxs pre-emption of the path search, so attempts to

put

>newer versions of dlls in the deploy directory weren't working.

I found a newer vcredist, installed it, and the problem went away.

thanks
Mark
"Steven Cheng [MSFT]" wrote:

>Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have

use

>PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be

put

>in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion

log

>and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you

tried

>putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally

due

>to some linked dependency of the existing reference that are not found

or

>if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead