Serious bug in .NET framework 2.0 - IShellLink interface crashes

[Elmue]

*Hello*

I wrote an application which runs perfect under .NET framework 1.1.

I was very disappointed, that a LOT of things do NOT work on *Framework
2.0*.
This framework is NOT downward compatible.

For one of the problems I could not yet find a solution or not even an
explanation:

My project loads a managed C++ DLL which uses the *IShellLink* interface
to resolve shortcuts.
The function ResolveShortCut() (see below) is called from the main C#
program in a thread loop to
resolve all links found on the desktop.

This works perfect on .NET framework 1.1

But on Framework 2.0 the behaviour is really strange and always different:

1.)
Sometimes the function ResolveShortCut() (see below) works 10 or even
100 times without problems.
2.)
Then suddenly it happens that *CoInitialize(0)* fails.
3.)
Another time *CoCreateInstance(CLSID_ShellLink, ...)* fails.
4.)
The next time at the point *i_ShLink->GetPath(...)* a crash appears
which cannot even be caught by a
try catch block (neither in managed C++ nor in the calling C# code !!)

_*Types of Crashes*_:
1.)
Sometimes the whole application crashes without any error message.
(the application silently disappears from the screen)
2.)
Another time I get a window which asks me to send the crash information
to Microsoft
3.)
Another time I get an error telling me something about "out of memory".
(which is nonsense)

___________________________________________________________________

_*Environment:*_

The problem appears on Windows 2000 and 2003.
I use Visual Studio 2003.

The *STRANGEST* thing is that this problem appears in the following cases:

1.)
The ONLY ever installed framework = 1.1 --> everything OK
2.)
framework 1.1 + 2.0 installed --> crashes *although* my application
loads the assemblies (mscoree.dll etc..) of framework 1.1 !!
3.)
framework 2.0 *UNINSTALLED* and only framework 1.1 installed --> crashes.


It is impossible to completely UNINSTALL framework 2.0 !
I saved the registry HKLM into a *.REG file, installed framework 2.0
then uninstalled it
and compared the registry with the saved file:
The result is shocking: *hundreds of entries in the Registry* and a
dozen of files are NOT removed !!


_*Conclusion:

*_If you ever installed framework 2.0 the computer is ruined.
It is impossible to completely remove framework 2.0.
My application still crashes even after framework 2.0 was uninstalled !!!!!
I have to install a fresh Windows to get it running again !!!!

I tried this on two different computers running Windows 2000 and 2003.
I can 100% reproduce this !

Additionally another function, which *CREATES *shortcuts also crashes
sometimes.
I did not yet test, which other functions using COM are also affected.

Is this a known problem ?
What can I do ?

Thanks in advance for any answer.

*Elmü*

____________________________________________________________________

Here is the code from my managed C++ DLL.

Please don't tell me that there is any bug in this code !
It runs PERFECTLY on framework 1.1 since years.


// this line may fail
hr = CoInitialize(0) called in the contructor.

hr = CoUninitialize(0) called in the destructor.


bool Utils::ResolveShortCut(String *ps_LNKfile, // IN: the link file
to resolve
String **pps_Path, // OUT: the target file
String **pps_CmdLine) // OUT: the command
line params (if any)
{
bool b_Ret = false;
IShellLink* i_ShLink;
IPersistFile* i_Persist;
WIN32_FIND_DATA k_Find;

WORD *u16_LNKfile =
(WORD*)Marshal::StringToHGlobalUni(ps_LNKfile).ToPointer();

// this line may fail
HRESULT hr = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER,
IID_IShellLink, (void**)&i_ShLink);
if (SUCCEEDED(hr))
{
hr = i_ShLink->QueryInterface(IID_IPersistFile, (void**)&i_Persist);
if (SUCCEEDED(hr))
{
hr = i_Persist->Load(u16_LNKfile, STGM_READ);
if (SUCCEEDED(hr))
{
hr = i_ShLink->Resolve(0, SLR_NO_UI | SLR_NOSEARCH | SLR_NOTRACK |
SLR_NOUPDATE | SLR_NOLINKINFO);
if (SUCCEEDED(hr))
{
char s8_Buf[MAX_PATH];
s8_Buf[0] = 0;

// this line may completely crash the whole application! (but
only sometimes)
hr = i_ShLink->GetPath(s8_Buf, MAX_PATH, &k_Find, SLGP_SHORTPATH);
if (SUCCEEDED(hr))
{
b_Ret = true;
*pps_Path = new String(s8_Buf);
}

s8_Buf[0] = 0;
hr = i_ShLink->GetArguments(s8_Buf, MAX_PATH);
if (SUCCEEDED(hr))
{
*pps_CmdLine = new String(s8_Buf);
}
}
}
i_Persist->Release();
}
i_ShLink->Release();
}
Marshal::FreeHGlobal(u16_LNKfile);
return b_Ret;
}

 

[Christopher Reed]

First of all, just because you are experiencing problems doesn't make it a bug in the Framework.

Now, based on what you have written, it appears that you are using elements that are still based on the 1.1 Framework. If this is the case, then you need to take steps to ensure that all program files are calling their associated Framework or you will experience issues with incompatibility between your 1.1 application file and the 2.0 Framework and vice versa. Also, you are using COM within your application and this alone can be a source of some of your issues, especially across multiple platforms.

May I add that I have been very pleased with the 2.0 Framework and I am overall pleased with its stability. Additionally, you noted that the 2.0 Framework isn't downward compatible and that was bad; well, IMNSHO, the 2.0 Framework shouldn't be downward compatible mainly because it should be moving forward with fixes and improved design from the previous versions.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."
Hello

I wrote an application which runs perfect under .NET framework 1.1.

I was very disappointed, that a LOT of things do NOT work on Framework 2.0.
This framework is NOT downward compatible.

For one of the problems I could not yet find a solution or not even an explanation:

My project loads a managed C++ DLL which uses the IShellLink interface to resolve shortcuts.
The function ResolveShortCut() (see below) is called from the main C# program in a thread loop to
resolve all links found on the desktop.

This works perfect on .NET framework 1.1

But on Framework 2.0 the behaviour is really strange and always different:

1.)
Sometimes the function ResolveShortCut() (see below) works 10 or even 100 times without problems.
2.)
Then suddenly it happens that CoInitialize(0) fails.
3.)
Another time CoCreateInstance(CLSID_ShellLink, ...) fails.
4.)
The next time at the point i_ShLink->GetPath(...) a crash appears which cannot even be caught by a
try catch block (neither in managed C++ nor in the calling C# code !!)

Types of Crashes:
1.)
Sometimes the whole application crashes without any error message.
(the application silently disappears from the screen)
2.)
Another time I get a window which asks me to send the crash information to Microsoft
3.)
Another time I get an error telling me something about "out of memory". (which is nonsense)

___________________________________________________________________

Environment:

The problem appears on Windows 2000 and 2003.
I use Visual Studio 2003.

The STRANGEST thing is that this problem appears in the following cases:

1.)
The ONLY ever installed framework = 1.1 --> everything OK
2.)
framework 1.1 + 2.0 installed --> crashes although my application
loads the assemblies (mscoree.dll etc..) of framework 1.1 !!
3.)
framework 2.0 UNINSTALLED and only framework 1.1 installed --> crashes.


It is impossible to completely UNINSTALL framework 2.0 !
I saved the registry HKLM into a *.REG file, installed framework 2.0 then uninstalled it
and compared the registry with the saved file:
The result is shocking: hundreds of entries in the Registry and a dozen of files are NOT removed !!


Conclusion:

If you ever installed framework 2.0 the computer is ruined.
It is impossible to completely remove framework 2.0.
My application still crashes even after framework 2.0 was uninstalled !!!!!
I have to install a fresh Windows to get it running again !!!!

I tried this on two different computers running Windows 2000 and 2003.
I can 100% reproduce this !

Additionally another function, which CREATES shortcuts also crashes sometimes.
I did not yet test, which other functions using COM are also affected.

Is this a known problem ?
What can I do ?

Thanks in advance for any answer.

Elmü

____________________________________________________________________

Here is the code from my managed C++ DLL.

Please don't tell me that there is any bug in this code !
It runs PERFECTLY on framework 1.1 since years.


// this line may fail
hr = CoInitialize(0) called in the contructor.

hr = CoUninitialize(0) called in the destructor.


bool Utils::ResolveShortCut(String *ps_LNKfile, // IN: the link file to resolve
String **pps_Path, // OUT: the target file
String **pps_CmdLine) // OUT: the command line params (if any)
{
bool b_Ret = false;
IShellLink* i_ShLink;
IPersistFile* i_Persist;
WIN32_FIND_DATA k_Find;

WORD *u16_LNKfile = (WORD*)Marshal::StringToHGlobalUni(ps_LNKfile).ToPointer();

// this line may fail
HRESULT hr = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER,
IID_IShellLink, (void**)&i_ShLink);
if (SUCCEEDED(hr))
{
hr = i_ShLink->QueryInterface(IID_IPersistFile, (void**)&i_Persist);
if (SUCCEEDED(hr))
{
hr = i_Persist->Load(u16_LNKfile, STGM_READ);
if (SUCCEEDED(hr))
{
hr = i_ShLink->Resolve(0, SLR_NO_UI | SLR_NOSEARCH | SLR_NOTRACK |
SLR_NOUPDATE | SLR_NOLINKINFO);
if (SUCCEEDED(hr))
{
char s8_Buf[MAX_PATH];
s8_Buf[0] = 0;

// this line may completely crash the whole application! (but only sometimes)
hr = i_ShLink->GetPath(s8_Buf, MAX_PATH, &k_Find, SLGP_SHORTPATH);
if (SUCCEEDED(hr))
{
b_Ret = true;
*pps_Path = new String(s8_Buf);
}

s8_Buf[0] = 0;
hr = i_ShLink->GetArguments(s8_Buf, MAX_PATH);
if (SUCCEEDED(hr))
{
*pps_CmdLine = new String(s8_Buf);
}
}
}
i_Persist->Release();
}
i_ShLink->Release();
}
Marshal::FreeHGlobal(u16_LNKfile);
return b_Ret;
}

 

[Kevin Spencer]

I might add that downward compatibility is not part of the .Net model. The
whole idea is that when a new version of the Framework comes out, it does
not *replace* the older versions, but is added to the system. This is part
of the model which prevents "DLL Hell." It is the same with multiple
versions of assemblies. Newer versions do not replace older versions; they
are installed side-by-side with the older versions, so that an app needing
either version has the version it needs.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

First of all, just because you are experiencing problems doesn't make it a
bug in the Framework.

Now, based on what you have written, it appears that you are using elements
that are still based on the 1.1 Framework. If this is the case, then you
need to take steps to ensure that all program files are calling their
associated Framework or you will experience issues with incompatibility
between your 1.1 application file and the 2.0 Framework and vice versa.
Also, you are using COM within your application and this alone can be a
source of some of your issues, especially across multiple platforms.

May I add that I have been very pleased with the 2.0 Framework and I am
overall pleased with its stability. Additionally, you noted that the 2.0
Framework isn't downward compatible and that was bad; well, IMNSHO, the 2.0
Framework shouldn't be downward compatible mainly because it should be
moving forward with fixes and improved design from the previous versions.
--
Christopher A. Reed
"The oxen are slow, but the earth is patient."
Hello

I wrote an application which runs perfect under .NET framework 1.1.

I was very disappointed, that a LOT of things do NOT work on Framework
2.0.
This framework is NOT downward compatible.

For one of the problems I could not yet find a solution or not even an
explanation:

My project loads a managed C++ DLL which uses the IShellLink interface to
resolve shortcuts.
The function ResolveShortCut() (see below) is called from the main C#
program in a thread loop to
resolve all links found on the desktop.

This works perfect on .NET framework 1.1

But on Framework 2.0 the behaviour is really strange and always different:

1.)
Sometimes the function ResolveShortCut() (see below) works 10 or even 100
times without problems.
2.)
Then suddenly it happens that CoInitialize(0) fails.
3.)
Another time CoCreateInstance(CLSID_ShellLink, ...) fails.
4.)
The next time at the point i_ShLink->GetPath(...) a crash appears which
cannot even be caught by a
try catch block (neither in managed C++ nor in the calling C# code !!)

Types of Crashes:
1.)
Sometimes the whole application crashes without any error message.
(the application silently disappears from the screen)
2.)
Another time I get a window which asks me to send the crash information to
Microsoft
3.)
Another time I get an error telling me something about "out of memory".
(which is nonsense)

___________________________________________________________________

Environment:

The problem appears on Windows 2000 and 2003.
I use Visual Studio 2003.

The STRANGEST thing is that this problem appears in the following cases:

1.)
The ONLY ever installed framework = 1.1 --> everything OK
2.)
framework 1.1 + 2.0 installed --> crashes although my application
loads the assemblies (mscoree.dll etc..) of framework 1.1 !!
3.)
framework 2.0 UNINSTALLED and only framework 1.1 installed --> crashes.


It is impossible to completely UNINSTALL framework 2.0 !
I saved the registry HKLM into a *.REG file, installed framework 2.0 then
uninstalled it
and compared the registry with the saved file:
The result is shocking: hundreds of entries in the Registry and a dozen of
files are NOT removed !!


Conclusion:

If you ever installed framework 2.0 the computer is ruined.
It is impossible to completely remove framework 2.0.
My application still crashes even after framework 2.0 was uninstalled
!!!!!
I have to install a fresh Windows to get it running again !!!!

I tried this on two different computers running Windows 2000 and 2003.
I can 100% reproduce this !

Additionally another function, which CREATES shortcuts also crashes
sometimes.
I did not yet test, which other functions using COM are also affected.

Is this a known problem ?
What can I do ?

Thanks in advance for any answer.

Elmü

____________________________________________________________________

Here is the code from my managed C++ DLL.

Please don't tell me that there is any bug in this code !
It runs PERFECTLY on framework 1.1 since years.


// this line may fail
hr = CoInitialize(0) called in the contructor.

hr = CoUninitialize(0) called in the destructor.


bool Utils::ResolveShortCut(String *ps_LNKfile, // IN: the link file to
resolve
String **pps_Path, // OUT: the target file
String **pps_CmdLine) // OUT: the command line
params (if any)
{
bool b_Ret = false;
IShellLink* i_ShLink;
IPersistFile* i_Persist;
WIN32_FIND_DATA k_Find;

WORD *u16_LNKfile =
(WORD*)Marshal::StringToHGlobalUni(ps_LNKfile).ToPointer();

// this line may fail
HRESULT hr = CoCreateInstance(CLSID_ShellLink, NULL,
CLSCTX_INPROC_SERVER,
IID_IShellLink, (void**)&i_ShLink);
if (SUCCEEDED(hr))
{
hr = i_ShLink->QueryInterface(IID_IPersistFile, (void**)&i_Persist);
if (SUCCEEDED(hr))
{
hr = i_Persist->Load(u16_LNKfile, STGM_READ);
if (SUCCEEDED(hr))
{
hr = i_ShLink->Resolve(0, SLR_NO_UI | SLR_NOSEARCH | SLR_NOTRACK |
SLR_NOUPDATE | SLR_NOLINKINFO);
if (SUCCEEDED(hr))
{
char s8_Buf[MAX_PATH];
s8_Buf[0] = 0;

// this line may completely crash the whole application! (but
only sometimes)
hr = i_ShLink->GetPath(s8_Buf, MAX_PATH, &k_Find,
SLGP_SHORTPATH);
if (SUCCEEDED(hr))
{
b_Ret = true;
*pps_Path = new String(s8_Buf);
}

s8_Buf[0] = 0;
hr = i_ShLink->GetArguments(s8_Buf, MAX_PATH);
if (SUCCEEDED(hr))
{
*pps_CmdLine = new String(s8_Buf);
}
}
}
i_Persist->Release();
}
i_ShLink->Release();
}
Marshal::FreeHGlobal(u16_LNKfile);
return b_Ret;
}

 

[Elmue]

Hello

First of all, just because you are experiencing problems doesn't make it
a bug in the Framework.

It !! IS !! definitely a serious bug because as I already wrote the crash
happens even if BOTH 1.1 AND 2.0 are installed.
Although my application loads only the DLL files from the folder
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\
it doesn't work anymore.

If - as Microsoft says - both frameworks may be installed side by side
then the newer framework should not disturb the functioning of the older one.
But it DOES !

Now, based on what you have written, it appears that you are using
elements that are still based on the 1.1 Framework.

My whole application (EXE and all DLLs) is build on Visual Studio 2003 for framework 1.1

If this is the
case, then you need to take steps to ensure that all program files are
calling their associated Framework

And how to do that ?
Can you give any details ?

Also, you are using COM within your application and
this alone can be a source of some of your issues, especially across
multiple platforms.

..NET does not offer any possibility to resolve shortcuts.
So I MUST use COM to do that.
And up to now it was never a problem !

May I add that I have been very pleased with the 2.0 Framework and I am
overall pleased with its stability.

May be YOU are pleased.
I am definitely not !

Additionally, you noted that the
2.0 Framework isn't downward compatible and that was bad; well, IMNSHO,
the 2.0 Framework shouldn't be downward compatible mainly because it
should be moving forward with fixes and improved design from the
previous versions.

OK
Then the user will have to install all frameworks in the future.
This means if you have one application that requires 1.1 and another
application that requires 2.0 and another application that requires framework 3.0
he will have to intall them all to assure proper working.
What a waste of diskspace!

Elmü

 

[Elmue]

Hello

I might add that downward compatibility is not part of the .Net model. The
whole idea is that when a new version of the Framework comes out, it does
not *replace* the older versions, but is added to the system. This is part
of the model which prevents "DLL Hell." It is the same with multiple
versions of assemblies. Newer versions do not replace older versions; they
are installed side-by-side with the older versions, so that an app needing
either version has the version it needs.

Nice this theory !
But it does not work in reality !

How is it possible that an application compiled for 1.1 is running perfectly
if only framework 1.1 is installed and that it crashes if you
ADDITIONALLY install framework 2.0 ?

Elmü

 

[Christopher Reed]

If your application is only using 1.1, why even install 2.0? If you don't
need it, don't install it!

As for running an application in a mixed .NET environment, look at the
Startup Settings Schema under the Configuration File Schema in the MSDN
documentation. This will show how to force your application to use a
particular Framework version.

Furthermore, this is not a bug. You caused it by running a 1.1 application
under 2.0 without verifying that the functionality you're using under 1.1 is
still compatible with 2.0. As the developer, it is your responsibility to
ensure that your programming is playing nice with the Framework, not the
other way. If you don't like it, then you can always move on to another
development platform.

 

[Kevin Spencer]

How is it possible that an application compiled for 1.1 is running

perfectly
if only framework 1.1 is installed and that it crashes if you
ADDITIONALLY install framework 2.0 ?

The operative word here is "you." This does not happen to *me*. It is
happening to *you* because *you* made a mistake.

See Christopher Reed's response for your solution.

A developer employs logic as his bread and butter. It is not logical to
assume that because something one is building crashes that it is due to a
bug in the .Net Framework. Note that I am not implying that there are no
bugs in the framework by this statement, only that it is not logical to make
that assumption when a problem occurs.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

 

[William Stacey [MVP]]

Thanks Christopher. I am confused on this from the docs:
"If the <supportedRuntime> element is not present in the application
configuration file, the version of the runtime used to build the application
is used."

This seems to suggest that if you don't supply anything, the runtime that
was used to build that app will be used. Is this correct?

--
William Stacey [MVP]

| If your application is only using 1.1, why even install 2.0? If you don't
| need it, don't install it!
|
| As for running an application in a mixed .NET environment, look at the
| Startup Settings Schema under the Configuration File Schema in the MSDN
| documentation. This will show how to force your application to use a
| particular Framework version.
|
| Furthermore, this is not a bug. You caused it by running a 1.1
application
| under 2.0 without verifying that the functionality you're using under 1.1
is
| still compatible with 2.0. As the developer, it is your responsibility to
| ensure that your programming is playing nice with the Framework, not the
| other way. If you don't like it, then you can always move on to another
| development platform.
| --
| Christopher A. Reed
| "The oxen are slow, but the earth is patient."
|
| | > Hello
| >
| >> First of all, just because you are experiencing problems doesn't make
it
| >> a bug in the Framework.
| >
| > It !! IS !! definitely a serious bug because as I already wrote the
crash
| > happens even if BOTH 1.1 AND 2.0 are installed.
| > Although my application loads only the DLL files from the folder
| > C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\
| > it doesn't work anymore.
| >
| > If - as Microsoft says - both frameworks may be installed side by side
| > then the newer framework should not disturb the functioning of the older
| > one.
| > But it DOES !
| >
| >> Now, based on what you have written, it appears that you are using
| >> elements that are still based on the 1.1 Framework.
| >
| > My whole application (EXE and all DLLs) is build on Visual Studio 2003
for
| > framework 1.1
| >
| >> If this is the
| >> case, then you need to take steps to ensure that all program files are
| >> calling their associated Framework
| >
| > And how to do that ?
| > Can you give any details ?
| >
| >> Also, you are using COM within your application and
| >> this alone can be a source of some of your issues, especially across
| >> multiple platforms.
| >
| > .NET does not offer any possibility to resolve shortcuts.
| > So I MUST use COM to do that.
| > And up to now it was never a problem !
| >
| >> May I add that I have been very pleased with the 2.0 Framework and I am
| >> overall pleased with its stability.
| >
| > May be YOU are pleased.
| > I am definitely not !
| >
| >> Additionally, you noted that the
| >> 2.0 Framework isn't downward compatible and that was bad; well, IMNSHO,
| >> the 2.0 Framework shouldn't be downward compatible mainly because it
| >> should be moving forward with fixes and improved design from the
| >> previous versions.
| >
| > OK
| > Then the user will have to install all frameworks in the future.
| > This means if you have one application that requires 1.1 and another
| > application that requires 2.0 and another application that requires
| > framework 3.0
| > he will have to intall them all to assure proper working.
| > What a waste of diskspace!
| >
| > Elmü
|
|

 

[Elmue]

Hello

Neither Christopher nor Kevin did read my description carefully
so they are not able to help me.

As for running an application in a mixed .NET environment, look at the
Startup Settings Schema under the Configuration File Schema in the MSDN
documentation. This will show how to force your application to use a
particular Framework version.

As I already wrote twice:
My application loads only DLLs from framework 1.1.
I checked this via SysInternals Process Spy.

You caused it by running a 1.1 application
under 2.0 without verifying that the functionality you're using under 1.1 is
still compatible with 2.0.

I already wrote twice that the problem still stays after UNinstalling 2.0 !!
It seems that one of the hundreds of registry keys which are NOT removed
by uninstalling causes the problem.

If your application is only using 1.1, why even install 2.0?

The answer is simple:
Because I have another application which requires 2.0.

___________________


Please no more answers from Christopher and Kevin !
They waste my time.

Is there anybody out there who experienced a similar probelm or who has read about it
and who is capable of reading my descritpion thoroughly up to the end ??

Thanks for any answers which help me to solve the problem
and which are not only theoretical discourses !

Elmü

 

[Christopher Reed]

I saw this explained once with respect to the 1.0 and 1.1 Frameworks. If
everything is equal, then I would agree with the basis premise that a 1.1
DLL with use the 1.1 Framework (noting of course that I'm probably being to
generic since the various SPs have different version numbers). However, in
this particular case, where the original poster has been installing and
uninstalling one or more versions of the Framework, this is probably the
safest approach because it should ensure that the application in question
(EXE or DLL) will use the expected version of the Framework. The specific
problem that would concern here is that the actual version the application
was compiled was not present; I believe that this should prevent an
application from working, but would throw up errors if there was anything in
the app that wasn't compatible with the Framework it was trying to use.

 

[Christopher Reed]

So, this application has not been compiled under 2.0 at all; yet, your
problems started after installing 2.0. Now, when we say that the 2.0
Framework was installed, are we talking about the 2.0 redist from Windows
Update, the SDK, or VS 2005?

 

[Robert Simpson]

My project loads a managed C++ DLL which uses the *IShellLink* interface
to resolve shortcuts.
The function ResolveShortCut() (see below) is called from the main C#
program in a thread loop to
resolve all links found on the desktop.
[snip]

2.)
Then suddenly it happens that *CoInitialize(0)* fails.

The red flag has just gone up.

Why are you calling CoInitialize(0)? Please tell me you aren't calling it
from the DLL ...

Robert

 

[Elmue]

Hello

Why are you calling CoInitialize(0)? Please tell me you aren't calling it
from the DLL ...

What should be the problem with CoInitialize ?
As I wrote I call it in the constructor of the managed C++ DLL.

But this is not the cause of the problem.
Because I also tried a completely different code which I found in the internet which does not use
any C++ code. It used COM import and directly loaded IShellLink from C# code.

And this code had the same problem although it worked WITHOUT CoInitialize.

But I already found a solution.
See my other posting !

Elmü

 

[Elmue]

Hi

Finally I solved the problem without the help of this newsgroup.
Here is the solution for all those, who encounter a problem of the following kind:

If you should find,
-- that your application crashes in a strange way (no try .. catch helps)
-- may be the crashes look different each time and seem unreproducable
-- that the function which crashes your appplication uses COM (e.g. IShellLink)
-- that you compiled with Visual Studio 2003 for Framework 1.1
-- that your application runs perfectly if ONLY framework 1.1 is installed.
-- that your application crashes if you ADDITIONALLY install framework 2.0
-- that your application STILL crashes EVEN after you UNINSTALLED framework 2.0
then this tip might help you:

If you call the function which accesses COM
(no matter if in C# via COM import or in managed C++)
from a thread then you must write:

Thread i_COMThread = new Thread(new ThreadStart(ThreadProc));
i_COMThread.ApartmentState = ApartmentState.STA;
i_COMThread.Start();

and the sun will shine again !!

Elmü

 

[Robert Simpson]

I didn't see any reply that had a solution.

I was unable to reproduce your problem. I wrote a managed C++ console app
to test it, and created a shortcut to notepad.exe. The code compiled and
ran with 0 errors:

// linktest.cpp : main project file.
#include "stdafx.h"
#include <shlobj.h>
#include <atlbase.h>

using namespace System;
using namespace System::Runtime::InteropServices;

int main(array<System::String ^> ^args)
{
CComPtr<IShellLink> pLink;
CComQIPtr<IPersistFile> pPersist;
HRESULT hr;

hr = pLink.CoCreateInstance(CLSID_ShellLink);
if (FAILED(hr)) return 1;

pPersist = pLink;
if (!pPersist) return 2;

hr = pPersist->Load(OLESTR("c:\\Notepad.lnk"), 0);
if (FAILED(hr)) return 3;

WIN32_FIND_DATA wfd;
WCHAR szPath[MAX_PATH];

hr = pLink->GetPath(szPath, MAX_PATH, &wfd, 0);
if (FAILED(hr)) return 4;

Console::WriteLine(Marshal:trToStringUni((IntPtr)szPath));

return 0;
}

 

[Robert Simpson]

This is exactly the kind of thing Larry mentions in his blog while
explaining that DLL's should never call CoInitialize() except when creating
their own threads.

Robert

 

[Willy Denoyette [MVP]]

| Hi
|
| Finally I solved the problem without the help of this newsgroup.
| Here is the solution for all those, who encounter a problem of the
following kind:
|
| If you should find,
| -- that your application crashes in a strange way (no try .. catch helps)
| -- may be the crashes look different each time and seem unreproducable
| -- that the function which crashes your appplication uses COM (e.g.
IShellLink)
| -- that you compiled with Visual Studio 2003 for Framework 1.1
| -- that your application runs perfectly if ONLY framework 1.1 is
installed.
| -- that your application crashes if you ADDITIONALLY install framework 2.0
| -- that your application STILL crashes EVEN after you UNINSTALLED
framework 2.0
| then this tip might help you:
|
| If you call the function which accesses COM
| (no matter if in C# via COM import or in managed C++)
| from a thread then you must write:
|
| Thread i_COMThread = new Thread(new ThreadStart(ThreadProc));
| i_COMThread.ApartmentState = ApartmentState.STA;
| i_COMThread.Start();
|
| and the sun will shine again !!
|
| Elmü
|

Can you also explain why it failed after you installed V2 of the framework?
Threads enter the MTA unless you initialized them otherwise, this behavior
did not change from V1 to V2. Also why are you suggesting to initialize all
your threads that use COM interop to enter the STA? Threads should use a COM
component's compatible apartment (STA or MTA). If you initialize a thread to
enter a STA and your COM component is 'Free' threaded, you'll take a huge
marshaling overhead and the sun will shine less brightly ;-).

Willy.

 

[Elmue]

Hello Willy

Can you also explain why it failed after you installed V2 of the framework?

All this stuff seems quite illogical to me.
I have no explanation for it.

Especially why installing version 2.0 influences my app although my app loads the framework 1.1 DLLs
is and stays an enigma for me.

The only thing I know is that it runs now and I will not invest more time
to find out what exactly are the causes or what else influences this strange behaviour.


Elmü

 

[Elmue]

This is exactly the kind of thing Larry mentions in his blog while
explaining that DLL's should never call CoInitialize() except when creating
their own threads.

Who is Larry ?

 

[Robert Simpson]

Sorry, when I wrote that it was after I had deleted a paragraph, and in my
mind I had still written the paragraph.

Larry Osterman

The blog in question:
http://blogs.msdn.com/larryosterman/archive/2004/05/12/130541.aspx

Robert