Serious bug in .NET framework 2.0 - IShellLink interface crashes

This is a multi-part message in MIME format.
--------------080507040709070501060408
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

*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;
}

--------------080507040709070501060408
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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) 
 
___________________________________________________________________ 
 
<big>Environment:</big> 
 
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. 
 
 
<tt>// this line may fail 
hr = CoInitialize(0) called in the contructor. 
 
hr = CoUninitialize(0) called in the destructor. 
</tt> 
 
<tt>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; 
} 
 
</tt> 
</body>
</html>

--------------080507040709070501060408--

Christopher
Sat Mar 25 07:19:17 CST 2006

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C64FDC.6DE71CE0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

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.
--=20
Christopher A. Reed
"The oxen are slow, but the earth is patient."
"Elmue" <abuse@gmx.de> wrote in message =
news:OJxO3FAUGHA.2156@tk2msftngp13.phx.gbl...
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 =3D 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=FC

____________________________________________________________________

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 =3D CoInitialize(0) called in the contructor.

hr =3D 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 =3D false;
IShellLink* i_ShLink;
IPersistFile* i_Persist;
WIN32_FIND_DATA k_Find;

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

// this line may fail
HRESULT hr =3D CoCreateInstance(CLSID_ShellLink, NULL, =
CLSCTX_INPROC_SERVER,
IID_IShellLink, (void**)&i_ShLink);
if (SUCCEEDED(hr))
{
hr =3D i_ShLink->QueryInterface(IID_IPersistFile, =
(void**)&i_Persist);
if (SUCCEEDED(hr))
{
hr =3D i_Persist->Load(u16_LNKfile, STGM_READ);
if (SUCCEEDED(hr))
{
hr =3D 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] =3D 0;

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

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

------=_NextPart_000_0007_01C64FDC.6DE71CE0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.2838" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>First of all, just because you are =
experiencing=20
problems doesn't make it a bug in the Framework.</DIV>
<DIV> </DIV>
<DIV>Now, based on what you have written, it =
appears=20
that you are using elements that are still based on the 1.1 =
Framework.  If=20
this is the case, then you need to take steps to ensure that all program =
files=20
are calling their associated Framework or you will experience issues =
with=20
incompatibility between your 1.1 application file and the 2.0 Framework =
and vice=20
versa.  Also, you are using COM within your application and this =
alone can=20
be a source of some of your issues, especially across multiple=20
platforms.</DIV>
<DIV> </DIV>
<DIV>May I add that I have been very pleased =
with the=20
2.0 Framework and I am overall pleased with its stability.  =
Additionally,=20
you noted that the 2.0 Framework isn't downward compatible and that was =
bad;=20
well, IMNSHO, the 2.0 Framework shouldn't be downward compatible mainly =
because=20
it should be moving forward with fixes and improved design from the =
previous=20
versions. -- Christopher A. Reed "The oxen are slow, but the =
earth is=20
patient."</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Elmue" <<A href=3D"mailto:abuse@gmx.de">abuse@gmx.de</A>> =
wrote in=20
message <A=20
=
href=3D"news:OJxO3FAUGHA.2156@tk2msftngp13.phx.gbl">news:OJxO3FAUGHA.2156=
@tk2msftngp13.phx.gbl</A>...</DIV>Hello I=20
wrote an application which runs perfect under .NET framework =
1.1. I was=20
very disappointed, that a LOT of things do NOT work on <FONT=20
color=3D#990000>Framework 2.0. This framework is NOT =
downward=20
compatible. For one of the problems I could not yet find a =
solution or=20
not even an explanation: My project loads a managed C++ DLL =
which uses=20
the IShellLink interface to =
resolve=20
shortcuts. The function ResolveShortCut() (see below) is called =
from the=20
main C# program in a thread loop to resolve all links found on the=20
desktop. This works perfect on .NET framework 1.1 But on =

Framework 2.0 the behaviour is really strange and always=20
different: 1.) Sometimes the function ResolveShortCut() (see =
below)=20
works 10 or even 100 times without problems. 2.) Then suddenly =
it=20
happens that CoInitialize(0) fails. 3.) Another time=20
CoCreateInstance(CLSID_ShellLink, ...) fails. 4.) The =
next time=20
at the point i_ShLink->GetPath(...) a crash appears which =
cannot=20
even be caught by a try catch block (neither in managed C++ nor in =
the=20
calling C# code !!) Types of =
Crashes: 1.) Sometimes=20
the whole application crashes without any error message. (the =
application=20
silently disappears from the screen) 2.) Another time I get a =
window=20
which asks me to send the crash information to =
Microsoft 3.) Another=20
time I get an error telling me something about "out of memory". (which =
is=20
=
nonsense) ________________________________________________________=
___________ <BIG>Environment:</BIG> The=20
problem appears on Windows 2000 and 2003. I use Visual Studio=20
2003. The STRANGEST thing is that this problem appears =
in the=20
following cases: 1.) The ONLY ever installed framework =3D =
1.1 =20
--> everything OK 2.) framework 1.1 + 2.0 installed --> =
crashes=20
although my application loads the assemblies (mscoree.dll =
etc..) of=20
framework 1.1 !! 3.) framework 2.0 UNINSTALLED and only =
framework=20
1.1 installed --> crashes. It is impossible to =
completely=20
UNINSTALL framework 2.0 ! I saved the registry HKLM into a *.REG =
file,=20
installed framework 2.0 then uninstalled it and compared the =
registry with=20
the saved file: The result is shocking: hundreds of entries in =
the=20
Registry and a dozen of files are NOT removed=20
!! Conclusion: If you ever installed =
framework=20
2.0 the computer is ruined. It is impossible to completely remove =
framework=20
2.0. My application still crashes even after framework 2.0 was =
uninstalled=20
!!!!! I have to install a fresh Windows to get it running again=20
!!!! I tried this on two different computers running Windows =
2000 and=20
2003. I can 100% reproduce this ! Additionally another =
function,=20
which CREATES shortcuts also crashes sometimes. I did not =
yet test,=20
which other functions using COM are also affected. Is this a =
known=20
problem ? What can I do ? Thanks in advance for any=20
=
answer. Elm=FC _____________________________________=
_______________________________ Here=20
is the code from my managed C++ DLL. Please don't tell me that =
there is=20
any bug in this code ! It runs PERFECTLY on framework 1.1 since=20
years. <TT>// =
this line may=20
fail hr =3D CoInitialize(0)   called in the=20
contructor. hr =3D CoUninitialize(0) called in the=20
destructor. </TT> <TT>bool Utils::ResolveShortCut(String=20
*ps_LNKfile,   // IN:  the link file to=20
=
resolve           &n=
bsp;           &nb=
sp;    =20
String **pps_Path,    // OUT: the target=20
=
file           &nbsp=
;            =
    =20
String **pps_CmdLine) // OUT: the command line params (if =
any) {  =20
bool            =
b_Ret =3D=20
false;   IShellLink*     =
i_ShLink;  =20
IPersistFile*   i_Persist;   WIN32_FIND_DATA=20
k_Find;   WORD *u16_LNKfile =3D=20
=
(WORD*)Marshal::StringToHGlobalUni(ps_LNKfile).ToPointer();   // this line may fail   HRESULT =
hr =3D=20
CoCreateInstance(CLSID_ShellLink, NULL,=20
=
CLSCTX_INPROC_SERVER,         =
            &=
nbsp;          =20
IID_IShellLink, (void**)&i_ShLink);   if =
(SUCCEEDED(hr))  =20
{     hr =3D =
i_ShLink->QueryInterface(IID_IPersistFile,=20
(void**)&i_Persist);     if=20
(SUCCEEDED(hr))     =
{       hr =3D=20
i_Persist->Load(u16_LNKfile, =
STGM_READ);      =20
if (SUCCEEDED(hr))      =20
{         hr =3D =
i_ShLink->Resolve(0,=20
SLR_NO_UI | SLR_NOSEARCH | SLR_NOTRACK=20
=
|            &n=
bsp;           &nb=
sp;         =20
SLR_NOUPDATE | =
SLR_NOLINKINFO);        =20
if (SUCCEEDED(hr))        =20
{           char=20
=
s8_Buf[MAX_PATH];         &nbs=
p;=20
s8_Buf[0] =3D 0; <FONT=20
color=3D#ff0000>          =
// this=20
line may completely crash the whole application! (but only=20
=
sometimes)         &nbs=
p; hr=20
=3D i_ShLink->GetPath(s8_Buf, MAX_PATH, &k_Find,=20
=
SLGP_SHORTPATH);         &nbsp=
; if=20
=
(SUCCEEDED(hr))          =
=20
=
{             =
b_Ret=20
=3D =
true;           &nbs=
p;=20
*pps_Path =3D new=20
=
String(s8_Buf);          =
=20
}           =
s8_Buf[0] =3D=20
0;           hr =3D=20
i_ShLink->GetArguments(s8_Buf,=20
MAX_PATH);           =
if=20
=
(SUCCEEDED(hr))          =
=20
=
{            =20
*pps_CmdLine =3D new=20
=
String(s8_Buf);          =
=20
}        =20
}       =
}      =20
i_Persist->Release();     }     =

i_ShLink->Release();   }  =20
Marshal::FreeHGlobal(u16_LNKfile);   return=20
b_Ret; } </TT> </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0007_01C64FDC.6DE71CE0--

Kevin
Sat Mar 25 07:30:16 CST 2006

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.

"Christopher Reed" <carttu@nospam.nospam> wrote in message
news:emWS67AUGHA.2444@TK2MSFTNGP14.phx.gbl...
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."
"Elmue" <abuse@gmx.de> wrote in message
news:OJxO3FAUGHA.2156@tk2msftngp13.phx.gbl...
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_LNKfi

Serious bug in .NET framework 2.0 - IShellLink interface crashes

Re: Serious bug in .NET framework 2.0 - IShellLink interface crashes by Christopher

Re: Serious bug in .NET framework 2.0 - IShellLink interface crashes by Kevin