regsvr32 error code 0x80004002

Norman Diamond

unread,

Mar 3, 2008, 5:08:06 AM3/3/08

to

Until December 2007 I could use Visual Studio 2005 to build DLLs using ATL.
Usually Visual Studio 2005 would register the DLLs during building (yeah,
there are still reasons to be an administrator while using Visual Studio).
When it failed, I could type a regsvr32 command into a command prompt.

Starting in December 2007, regsvr32 gives error code 0x80004002,
Interface Not Supported.
(Actual wording: インターフェースがサポートされていません)

Visual Studio 2005 gives error message PRJ0050 when trying to build, but the
underlying reason is the same, when Visual Studio 2005 tries to register the
DLL.

In December 2007 I also tried reregistering an old copy of my DLL, built in
October 2007 and properly registered in October 2007. The error is the
same, 0x80004002. The old DLL file was the same, obsolete because it was
built before I added features to its source code, but it registered properly
in October and then failed in December.

The same problem started on my boss's machine in or after December 2007.

In December 2007 I posted the same question (in the MFC newsgroup only), and
several kind people tried to help, but the problem continues unchanged.

I created a new ATL DLL project. The error is the same.

What got broken in December 2007, was unbroken before that but remains
broken now? How can I fix it? Does anyone know how to get regsvr32 working
again on ATL DLLs?

[Some MSDN and Google searching yielded the following useless information.]

[Windows Update gets broken similarly. Well I don't have trouble with
Windows Update, I'm trying to register one of my own DLLs that only uses
ATL80 and CRT80.]

[Visual Basic 5 contains a working version of comcat.dll version 4.71. If I
find Visual Basic 5 then I can try overwriting Windows XP SP2's version of
comcat.dll with this old version. I doubt it since I didn't have Visual
Basic 5 any time in 2007 or now.]

[Windows Server 2003 Volume Shadowing Services gets broken similarly. XP
doesn't have a UI for Volume Shadowing Services, but it has some of the same
DLLs, so I reregistered all of the DLLs that exist. Those worked. But
regsvr32 still refuses to register my DLL.]

Kerem Gumrukcu

unread,

Mar 3, 2008, 6:19:51 AM3/3/08

to

Hi Norman,

in Situations like this i always use Process Monitor as a first look
and track back the calls regsvr32 and your target binary/ocx/dll
does by examining all events like registry/filesystem/call stack
to see which of the events can give me more special in-depth
look, whats behind the scene. Try Process Monitor as first option
to see what fails and where. Dont forget to configure Symbols for
your os to see function calls that have been made and where what
fails,...

Regards

K.

--
-----------------------
Beste Grusse / Best regards / Votre bien devoue
Kerem Gumrukcu
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------

"This reply is provided as is, without warranty express or implied."
"Norman Diamond" <ndia...@newsgroup.nospam> schrieb im Newsbeitrag
news:%23hMV%23ZRfI...@TK2MSFTNGP06.phx.gbl...

_@_roadrunner_com Ivo Beltchev

unread,

Mar 3, 2008, 11:31:39 AM3/3/08

to

"Norman Diamond" <ndia...@newsgroup.nospam> wrote in message news:%23hMV%23ZRfI...@TK2MSFTNGP06.phx.gbl...

_@_roadrunner_com Ivo Beltchev

unread,

Mar 3, 2008, 11:35:13 AM3/3/08

to

Can it be related to the new VS2005 service pack? Maybe some app you installed recently updated the CRT dlls to their latest SP1 version, but your Visual Studio is not updated. And maybe you are running in some incompatibility between your code and the new CRT.

"Norman Diamond" <ndia...@newsgroup.nospam> wrote in message news:%23hMV%23ZRfI...@TK2MSFTNGP06.phx.gbl...

Stefan Kuhr

unread,

Mar 3, 2008, 11:38:33 AM3/3/08

to

Hello Norman,

Norman Diamond wrote:
> Until December 2007 I could use Visual Studio 2005 to build DLLs using ATL.
> Usually Visual Studio 2005 would register the DLLs during building (yeah,
> there are still reasons to be an administrator while using Visual Studio).
> When it failed, I could type a regsvr32 command into a command prompt.
>
> Starting in December 2007, regsvr32 gives error code 0x80004002,
> Interface Not Supported.
> (Actual wording: インターフェースがサポートされていません)
>

Have you tried setting a breakpoint in DllRegisterServer of your DLL?
Maybe you get some clue what goes on by single-stepping through the
source code of this function?

--
Stefan

Norman Diamond

unread,

Mar 3, 2008, 7:24:33 PM3/3/08

to

I think that VS2005 SP1 cannot be the problem because I had installed that
several months earlier. However, it seems I installed some other update to
VS2005 on December 7, 2007. I wonder what.

Aha, .Net Framework 2 SP1 and .Net Framework 3 SP1 were installed on
December 7, 2007. My DLL is unmanaged only, but it sure looks like these
.Net Framework patches damaged the registration of unmanaged DLLs.

"Ivo Beltchev" <ivo _@_ roadrunner _ com> wrote in message
news:uG5EQyUf...@TK2MSFTNGP03.phx.gbl...

Norman Diamond

unread,

Mar 3, 2008, 7:30:44 PM3/3/08

to

"Stefan Kuhr" <kust...@gmx.li> wrote in message
news:eAm7r1Uf...@TK2MSFTNGP03.phx.gbl...

One wizard-generated function is DllRegisterServer. The call to
_AtlModule.DllRegisterServer succeeds. The call to PrxDllRegisterServer
fails, but it used to succeed. Temporarily I removed the definition of
macro _MERGE_PROXYSTUB so that PrxDllRegisterServer will not be called.
However, I still wonder why this broke starting in December 2007.

Norman Diamond

unread,

Mar 3, 2008, 9:40:42 PM3/3/08

to

Furthermore the thing works on Vista SP1. VS2005 SP1 + hotfix for Vista +
Vista SDK are installed on this Vista SP1 machine, but I did not compile the
DLL there. I only copied the DLL from an XP machine where I'd compiled it,
and on the Vista machine I opened a command prompt with administrative
privileges. regsvr32 succeeded.

So it really looks like .Net Framework 2 SP1 or .Net Framework 3 SP1 damaged
part of the Win32 APIs in XP.

"Norman Diamond" <ndia...@newsgroup.nospam> wrote in message

news:%23daFg4Y...@TK2MSFTNGP05.phx.gbl...

Charles Wang[MSFT]

unread,

Mar 4, 2008, 3:00:40 AM3/4/08

to

Hi Norman,
Regarding this issue, first I would like to confirm with you the following
two questions:
1. Did you use an administrator account to build and register your ATL DLL?
2. Did you build your ATL project with /MANIFEST option?
Right click your project, click Properties, expand Configuration
Properties->Linker->Manifest File, and set "Generate Manifest" to Yes. If
it was set to Yes, please rebuild your project and then re-register your
DLL to see if it helps.

Both CRT 8.0 and ATL 8.0 DLLs are accessible only via WinSxS, if /MANIFEST
is not enabled, regsvr32.exe attempting to load the DLLs may fail because
the dependent WinSxS assemblies (CRT and ATL) cannot be loaded.

If you have any other questions or concerns, please feel free to let me
know.

Best regards,
Charles Wang
Microsoft Online Community Support
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

Norman Diamond

unread,

Mar 4, 2008, 7:37:59 PM3/4/08

to

Mr. Wang, thank you for your questions.

1. Yes I did use an administrator account, both when compiling with Visual
Studio 2005 SP1, and when typing the regsvr32 command.

2. Yes, the properties for the ATL DLL project already say to generate a
manifest. I did not touch that setting and only opened it now to view it.
Also here is part of the linker command line shown in the properties page:
/MANIFEST /MANIFESTFILE:"Release\censored name.dll.intermediate.manifest"
The real project name also includes a space, but the real command line
includes those quotation marks.

"Charles Wang[MSFT]" <chan...@online.microsoft.com> wrote in message
news:9e51e3cf...@TK2MSFTNGHUB02.phx.gbl...

Charles Wang[MSFT]

unread,

Mar 5, 2008, 7:37:16 AM3/5/08

to

Hi Norman,
Did your ATL DLL reference other DLLs? You can use Dependency Walker
(depends.exe) to check if there are any dependency component missed.

Also I recommend that you check your ATL DLL manifest content to see what
the assembly version is. Compare it with the assemblies in your
%Windir%\WinSxS folder to see if the assembly version match the latest
version of the related assembly in your WinSxS folder. Please also post
your ATL DLL manifest content here for further research. If your ATL DLL
was compiled with embedded manifest, you can check your ATL DLL manifest
via:
Open VS2005, click File->Open->File, select your ATL DLL, click OK, expand
RT_MANIFEST folder, click the icon 1 and then copy the ASCII characters out
to notepad.

Look forward to your response.

Drew

unread,

Mar 5, 2008, 2:26:37 PM3/5/08

to

You can sometimes get useful information by loading regsvr32 into
Dependency Walker and doing a profile of your DLL.

www.dependencywalker.com

Drew

"Norman Diamond" <ndia...@newsgroup.nospam> wrote in message
news:%23hMV%23ZRfI...@TK2MSFTNGP06.phx.gbl...

Norman Diamond

unread,

Mar 5, 2008, 8:53:29 PM3/5/08

to

DLLs referenced by mine are:

c:\windows\system32\KERNEL32.DLL
c:\windows\system32\USER32.DLL
c:\windows\system32\OLE32.DLL
c:\windows\system32\OLEAUT32.DLL
c:\windows\winsxs\x86_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_cbb27474\ATL80.DLL
c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\MSVCR80.DLL

The contents of file
censored name.dll.intermediate.manifest
in the Release directory are as follows:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.ATL'
version='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>

The following files are all version 8.00.50727.762:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_cbb27474\ATL80.dll
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcm80.dll
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcp80.dll

Now I see there also exist newer CRT files, version 8.00.50727.1433:

C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\msvcr80.dll
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\msvcm80.dll
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\msvcp80.dll

but there is not a newer ATL file to match.

> Open VS2005, click File->Open->File, select your ATL DLL, click OK, expand
> RT_MANIFEST folder, click the icon 1

There is an icon 2 but no icon 1. Here is the text from expanding icon 2:

"Charles Wang[MSFT]" <chan...@online.microsoft.com> wrote in message

news:iTetp2r...@TK2MSFTNGHUB02.phx.gbl...

Charles Wang[MSFT]

unread,

Mar 6, 2008, 6:55:12 AM3/6/08

to

Hi Norman,
Thanks for your response.

I think that this issue was caused by assembly redirection. Since .NET 3.0
SP1 was installed, the Microsoft.VC80.CRT assembly was redirected to the
newest version according to policy file which you can find in
%Windir%\WinSxS folder, however according to your DLL manifest, your
assembly should reference the old version. This may caused this error.

I recommend that you first try using private assemblies to see if it helps.
Manually copy the related DLLs and manifests to your COM application folder
and rename the manifest file according to this article:
Private Assemblies
http://msdn2.microsoft.com/en-us/library/aa375674.aspx

Regarding redistributing VC++ DLL as private assemblies, you can also refer
to the following articles:
Redistributing Visual C++ Files
http://msdn2.microsoft.com/en-us/library/ms235299(VS.80).aspx
Choosing a Deployment Method
http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx

Hope this helps. If you have any other questions or concerns, please feel

free to let me know.

Best regards,

Norman Diamond

unread,

Mar 6, 2008, 7:09:22 PM3/6/08

to

My understanding now is as follows:

If a DLL was built with Visual Studio 2005 SP1 and was compiled to use the
corresponding version of the CRT and ATL libraries, then distribution of the
DLL must be accompanied by redistribution of the corresponding CRT and ATL
libraries. Private assemblies must be used. There is no other way.

Furthermore, this solution must be applied to DLLs that were already built
and distributed, even when we thought we had finished their development.

The reason is:

The creator of the DLL cannot predict which end users' machines will have
.Net Framework 3.0 SP1 installed. Even though the DLL does not use .Net,
the DLL will be affected on an end user's machine if .Net Framework 3.0 SP1
is installed on the end user's machine.

It is time to add to my previous observation:

DLL Hell .Net is worse than DLL Hell Classic -- even for DLLs that do not
use .Net.

"Charles Wang[MSFT]" <chan...@online.microsoft.com> wrote in message

news:AYh40D4f...@TK2MSFTNGHUB02.phx.gbl...

David Ching

unread,

Mar 6, 2008, 8:44:55 PM3/6/08

to

"Norman Diamond" <ndia...@newsgroup.nospam> wrote in message

news:uVkBHe%23fIH...@TK2MSFTNGP04.phx.gbl...

> My understanding now is as follows:
>
> If a DLL was built with Visual Studio 2005 SP1 and was compiled to use the
> corresponding version of the CRT and ATL libraries, then distribution of
> the DLL must be accompanied by redistribution of the corresponding CRT and
> ATL libraries. Private assemblies must be used. There is no other way.
>
> Furthermore, this solution must be applied to DLLs that were already built
> and distributed, even when we thought we had finished their development.
>
> The reason is:
>
> The creator of the DLL cannot predict which end users' machines will have
> .Net Framework 3.0 SP1 installed. Even though the DLL does not use .Net,
> the DLL will be affected on an end user's machine if .Net Framework 3.0
> SP1 is installed on the end user's machine.
>
> It is time to add to my previous observation:
>
> DLL Hell .Net is worse than DLL Hell Classic -- even for DLLs that do not
> use .Net.
>

I do hope Charles Wang replies with some clarification of what he meant.
Surely he did not mean to imply that .NET 3.0 SP1 broke the SxS installation
of the VC2005 SP1 redistributables so that only private assemblies would
work from then on.

-- David

Charles Wang[MSFT]

unread,

Mar 7, 2008, 4:00:24 AM3/7/08

to

Hi Norman,
Thanks for your response.

I agree to your analysis regarding that the installation of .Net Framework
3.0 SP1 may affect those old applications or DLLs which uses old version
libraries. The problem is assembly redirection defined in publisher
configuration file (those policy files in WinSxS folder).

Regarding DLL hell, I want to talk it from another perspective. It is very
important for a developer to choose a proper deployment method for his
target machine. You also need to make a decision of using private
assemblies or using shared assemblies before you deploy your applications
or DLLs. If you choose shared assemblies, you need to ensure that the
target machine will not install the newer VC++ redistributable libraries.
If you could not ensure this, you need to consider if you should use an
application configuration file for your application (.exe) or use private
assemblies instead.

Currently for those DLLs who need to be registered via regsvr32.exe, there
is no better way to work around the registering issue except using private
assemblies. However there is a new feature for creating COM in Visual
Studio 2005, you can create isolated COM which is no need to be registered
via regsvr32.exe. You may refer to:
Isolated COM
http://qualapps.blogspot.com/2007/06/isolated-com.html
Isolated COM Activation tutorial:
http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
Isolated COM Activation sample project:
http://download.microsoft.com/download/2/e/9/2e9bde04-3af1-4814-9f1e-733f732
369a3/RegFreeCOM.exe

For applications (.exe), using private assemblies is not the only way to
work around assembly redirection, you can also use application
configuration file to define the redirection rule for your application.
There are two articles talking about this:
Per-application Configuration on Windows XP
http://msdn2.microsoft.com/en-us/library/aa375667(VS.85).aspx

Per-application Configuration on Windows Server 2003
http://msdn2.microsoft.com/en-us/library/aa375660(VS.85).aspx

I once resolved a customer's issue for using application configuration file
and I would like to share the resolution here for you:
============================================================================
=======================
Application configuration file indeed works for unmanaged applications on
both Windows XP and Windows Server 2003, however they have some different
configuration settings.

On Windows XP, you need not to specify the publisherPolicy section. I used
the following configuration file (ManiConsTest.exe.config) for my test
program ManiConsTest.exe:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

This is enough for Windows XP. However on Windows Server 2003, the things
became more complex. To have it work, you must install Application
Compatibility Toolkit 5.0 (ACT 5.0) and configure the EnableAppConfig flag
for your application. Please refer to the following steps in detail:
1. Download and Install ACT 5.0 (Application Compatibility Toolkit.msi)
from this link:
http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-
b45e-492dd6da2971&DisplayLang=en

2. Open Start->All Programs->Microsoft Application Compatibility Toolkit
5.0->Compatibility Administrator;
3. After Compatibility Administrator is opened, first click the Save button
to save the database, rename it as AppCompatDB, input the file name as
appcompatdb and click Save.
4. Right click AppCompatDB database, select Create New->Application Fix...;
input your application name to the field "Name of the program to be fixed"
(I input ManiConsText here for my program), select your Program file
location by clicking Browse button, and click Next;
5. Select None as Compatibility Modes, click Next, select EnableAppConfig,
click Next, click Finish, and then Save your database by first selecting
your database and clicking the Save button;
6. Right click your database, select Install and you will find that the
database will be installed under the Installed Databases folder.
7. After the above steps, you have successfully configured the
EnableAppConfig for your application, and now you just need one
application configuration file (xxx.exe.config) which is as following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

After the above steps finished, you can run your program and then you will
find that it only loads the assemblies with the version 8.0.50727.42.
============================================================================
=========================

I cannot say DLL hell is eliminated in every condition; however I think
that with manifest we eliminate the old fashion DLL hell problem.

You know DLL hell is not so frightful, because we always have methods to
work around it. :-) If you have any other questions or concerns, please
feel free to let me know. I am very glad to work with you for further
research.

Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support

=========================================================
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: msd...@microsoft.com.
=========================================================

Charles Wang[MSFT]

unread,

Mar 7, 2008, 4:04:25 AM3/7/08

to

Thanks David,
The installation of .NET 3.0 SP1 will result in assembly redirection from
old version to new version. This will affect those old applications who use
old version assemblies.
For more information, please refer to my last reply to Norman.

Have a great day!

Best regards,
Charles Wang
Microsoft Online Community Support

=========================================================
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: msd...@microsoft.com.
=========================================================

David Ching

unread,

Mar 7, 2008, 11:49:43 AM3/7/08

to

"Charles Wang[MSFT]" <chan...@online.microsoft.com> wrote in message

news:7P$z4GDgI...@TK2MSFTNGHUB02.phx.gbl...

> Regarding DLL hell, I want to talk it from another perspective. It is very
> important for a developer to choose a proper deployment method for his
> target machine. You also need to make a decision of using private
> assemblies or using shared assemblies before you deploy your applications
> or DLLs. If you choose shared assemblies, you need to ensure that the
> target machine will not install the newer VC++ redistributable libraries.
> If you could not ensure this, you need to consider if you should use an
> application configuration file for your application (.exe) or use private
> assemblies instead.
>

Hi Charles, well this puts us app developers in a bind. Because we cannot
look into a crystal ball to see the future and what manner of newer versions
of libraries Microsoft will deploy in the future, let alone whether our app
is going to be compatible with those new versions or not. We take it on
faith Microsoft will not break anything major in these service releases, so
by default we do not use private assemblies or per-application configuration
to lock into the version we have tested with. So if Microsoft does release
a service pack that breaks our app, we now have to a) find out about this
from angry customers and as Norman's experience highlights, it is not easy
to find out which Microsoft service pack is breaking the app, or even if it
is a service pack at all or some other machine-dependent configuration; b)
scurry to release a per-application configuration update for our app or
re-deploy our app with private assemblies. I think you will agree that
Microsoft is putting an undue burdan on app developers to drop everything to
fix a fire that Microsoft caused by releasing a service pack or hotfix
without warning.

> Currently for those DLLs who need to be registered via regsvr32.exe, there
> is no better way to work around the registering issue except using private
> assemblies. However there is a new feature for creating COM in Visual
> Studio 2005, you can create isolated COM which is no need to be registered
> via regsvr32.exe. You may refer to:
> Isolated COM
> http://qualapps.blogspot.com/2007/06/isolated-com.html
> Isolated COM Activation tutorial:
> http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
> Isolated COM Activation sample project:
> http://download.microsoft.com/download/2/e/9/2e9bde04-3af1-4814-9f1e-733f732
> 369a3/RegFreeCOM.exe
>

This is a great new feature, essentially it is private assemblies for COM
objects.

What now? We need to tell our customers running our apps on Windows Server
2003 that they need to install this App Compat Toolkit and configure it to
allow our app to use a non-default version of a library? What kind of
nonsense is this? We app developers bend over backwards to give our
customers a trouble free deployment, and the best Microsoft comes up with is
force them to install some toolkit and configure it? Maybe MS can afford
that kind of tech support, but most of us can't.

> I cannot say DLL hell is eliminated in every condition; however I think
> that with manifest we eliminate the old fashion DLL hell problem.
>
> You know DLL hell is not so frightful, because we always have methods to
> work around it. :-) If you have any other questions or concerns, please
> feel free to let me know. I am very glad to work with you for further
> research.
>

Thanks for all the useful info, Charles, but this is far too difficult.

-- David

george...@yahoo.com

unread,

Mar 7, 2008, 3:16:51 PM3/7/08

to

On Mar 6, 4:09 pm, "Norman Diamond" <ndiam...@newsgroup.nospam> wrote:
> My understanding now is as follows:
>
> If a DLL was built with Visual Studio 2005 SP1 and was compiled to use the
> corresponding version of the CRT and ATL libraries, then distribution of the
> DLL must be accompanied by redistribution of the corresponding CRT and ATL
> libraries. Private assemblies must be used. There is no other way.
>
> Furthermore, this solution must be applied to DLLs that were already built
> and distributed, even when we thought we had finished their development.
>
> The reason is:
>
> The creator of the DLL cannot predict which end users' machines will have
> .Net Framework 3.0 SP1 installed. Even though the DLL does not use .Net,
> the DLL will be affected on an end user's machine if .Net Framework 3.0 SP1
> is installed on the end user's machine.
>
> It is time to add to my previous observation:
>
> DLL Hell .Net is worse than DLL Hell Classic -- even for DLLs that do not
> use .Net.
>

> "Charles Wang[MSFT]" <chang...@online.microsoft.com> wrote in message

> > ======================================================- Hide quoted text -
>
> - Show quoted text -

Hi Norman,

We can determine if CRT/ATL SxS is the cause of the regsvr32 failure
or not by looking into the Event Viewer. There should be entries
saying which VC assembly failed to load (if that is the cause).
Absence of such entries indicate that there is no problem with loading
CRT/ATL.

I installed the Microsoft .NET Framework 3.0 Service Pack 1 on a
machine with VS2005+SP1 and things seem to working fine.

Please, let us know how this goes. We are very interested in
understanding this scenario.

Thanks,
Visual C++ Libraries
George Mileka

Norman Diamond

unread,

Mar 10, 2008, 3:38:16 AM3/10/08

to

> it is not easy to find out which Microsoft service pack is breaking the
> app, or even if it is a service pack at all or some other
> machine-dependent configuration;

Double-Bingo.

The same problem started occuring on my boss's machine in January 2008, and
the cause is not .Net Framework 3 SP1. My boss installed .Net Framework 2
SP1 on that date. He has not installed any version higher than 2. (And the
DLL doesn't use any .Net Framework.)

Now by coincidence, with a previous version of this same DLL, I was able to
get private assemblies working in Windows XP SP2 and Vista, but not Windows
2000 SP4. So in a client application in C#, I try to "new" an object, if
that fails then I shell out to regsvr32, and if that also fails then I give
up. In Windows 2000 SP4 (and XP SP2 and Vista), prior to the December .Net
service packs, regsrv32 had no problem. On XP and Vista I can repeat the
effort to avoid needing regsrv32 at run time.

Regardless, Visual Studio 2005 SP1 knows that I'm compiling a DLL, so it
still tries to register the resulting DLL, irritating me and confusing my
boss. I already had to repeat the same explanation to him twice, and I get
dinged for being insufficiently communicative.

"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:FmeAj.4784$fX7....@nlpi061.nbdc.sbc.com...

Norman Diamond

unread,

Mar 10, 2008, 3:38:19 AM3/10/08

to

> We can determine if CRT/ATL SxS is the cause of the regsvr32 failure or
> not by looking into the Event Viewer. There should be entries saying which
> VC assembly failed to load (if that is the cause).

Oh yeah, how could I forget. OK, just now I reproed the bug with a version
of the DLL that was built in October 2007 and could be regsvr32'd then, but
which has yielded this bug ever since December 2007. It did repro again
just now, but there are no relevant events in the Event Viewer.

If I recall correctly, this kind of event was obscurely located in the
System log instead of the Application log. But just now I checked both, and
there's no event. So the problem isn't that an assembly failed to load,
it's that a current assembly is failing at something that an older version
was succeeding at.

<george...@yahoo.com> wrote in message
news:3233cff6-3681-4d50...@n77g2000hse.googlegroups.com...

Charles Wang[MSFT]

unread,

Mar 10, 2008, 7:35:53 AM3/10/08

to

Hi David,
Thanks for your feedback.

I do understand a developer's pain on this. I once consulted some
developers regarding this issue. Someone told me that actually this has a
design consideration, security. It forces all the applications with the
shared assemblies to use the latest version. Consider this may break
existing applications, it allows you to use application configuration file
or private assembly to resolve this issue. For ACT, application
configuration file, private assemblies, etc, these should be decided before
you deploy them to your customers. As a formal software, it is very common
to build a setup program which can hide those fussy details to your
customer. You can also have your setup program check the current windows OS
version and conditionally install the matched files on it. Appreciate your
understanding that any architecture design change may inevitably bring some
inconveniences, not only for Microsoft but also for any other software
company, however there are still many positive aspects we can see.

Also I would like to let you know that we value your any good suggestions
or feedbacks on improving Microsoft products and really appreciate if you
could submit your suggestions or feedbacks via
https://connect.microsoft.com at your convenience so that our product team
can hear your voice and continously improve our products. Thank you!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
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: msd...@microsoft.com.
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================

Charles Wang[MSFT]

unread,

Mar 10, 2008, 7:48:38 AM3/10/08

to

Hi Norman,
For windows 2000, actually it is not recommended to use private assemblies
since it does not support manifest-based binding.
On an operating system that does not support manifest-based binding
(Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium
Edition, Windows 2000), private assembly deployment method is not
recommended. You are strongly urged to use MSMs instead. If you attempt to
install, this is what happens:
Your application is installed in the specified target folder.
By default, the operating system loader won't find the CRT and MFC DLLs.
Microsoft.VC80.CRT and Microsoft.VC80.MFC have to be added to the PATH.

For more information, please refer to:
How to: Deploy using a Setup and Deployment Project
http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx

In conclusion, if you use Visual C++ 8.0/9.0 to develop DLLs or EXEs, it is
recommended that you deploy your DLLs with private assembly deployment on
Windows XP or later OS; while for Windows 2000 and previous OS, deploy them
with MSMs.

Please feel free to let me know if you have any other questions or
concerns. Have a nice day!

Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================
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: msd...@microsoft.com.
=========================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

=========================================================

predatorsw

unread,

Oct 28, 2008, 7:04:01 PM10/28/08

to

"David Ching" wrote:
>
> I do hope Charles Wang replies with some clarification of what he meant.
> Surely he did not mean to imply that .NET 3.0 SP1 broke the SxS installation
> of the VC2005 SP1 redistributables so that only private assemblies would
> work from then on.
>

Apparently the short answer is "Yes, Microsoft broke SXS installation of
VS2005 SP1 redistributables. You have to deploy using only private
assemblies."

Why did Microsoft waste any time developing SxS if they were simply going to
turn around and break it in exactly the same way that created DLL hell to
begin with?

It's been a few months since these posts, has any new magical fix come down
the pipe so that I don't have to rebuild every single one of my applications
simply because Microsoft can't be bothered with the fact they broke older
applications?