Smart Pointers Crash in Windows 2000 but not in Windows XP 
Author Message
 Smart Pointers Crash in Windows 2000 but not in Windows XP

Hi!

I have a problem that has been giving me trouble for ages.
I have an EXE that calls a COM component in a library application.

The smart pointer (from the imported dll) is instantiated only when
required, as calls are infrequent.

The second time an attempt is made to call CreateInstance, the
application crashes. This crash though only happens when the
application is running on a Windows 2000 (SP3) machine. If it is
running on an XP machine the code works correctly.

The pointer is a local variable and should clear up once it drops out
of scope. I have tried both this, and also calling .Release()
explicitly on the pointer when I am done with it, but neither of these
methods seems to work.

What's even more curious is that I have some apps that require they be
built in VC6, due to 3rd-party components, and they have exactly the
same behaviour in regards to the smart pointers as the other
applications that have been built under VC7.

I've also noticed that the try-catch blocks around the CreateInstance
method do not seem to catch the error.

Has anyone had a similar problem, or any ideas on what is going wrong?

Thanks in advance,

   Martin



Mon, 28 Nov 2005 20:51:06 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
Are there threads involved?
Is it apartment, multithreaded?

I had a similar funny on one COM module and removing aggregation seemed to
fix it.

Post a little code so we can see what you doing, may just be a little
gotcha.


Quote:
> Hi!

> I have a problem that has been giving me trouble for ages.
> I have an EXE that calls a COM component in a library application.

> The smart pointer (from the imported dll) is instantiated only when
> required, as calls are infrequent.

> The second time an attempt is made to call CreateInstance, the
> application crashes. This crash though only happens when the
> application is running on a Windows 2000 (SP3) machine. If it is
> running on an XP machine the code works correctly.

> The pointer is a local variable and should clear up once it drops out
> of scope. I have tried both this, and also calling .Release()
> explicitly on the pointer when I am done with it, but neither of these
> methods seems to work.

> What's even more curious is that I have some apps that require they be
> built in VC6, due to 3rd-party components, and they have exactly the
> same behaviour in regards to the smart pointers as the other
> applications that have been built under VC7.

> I've also noticed that the try-catch blocks around the CreateInstance
> method do not seem to catch the error.

> Has anyone had a similar problem, or any ideas on what is going wrong?

> Thanks in advance,

>    Martin



Tue, 29 Nov 2005 00:29:30 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
I doubt there is anything wrong with the smart pointer per se. If your COM
object crashes the second time it is instantiated, this is strongly
suggestive of a memory corruption problem.

What does your COM object do? What resources does it allocate? When and how
are they freed?

Can you put a breakpoint in FinalConstruct? Is it reached on the second
call?


Quote:
> Hi!

> I have a problem that has been giving me trouble for ages.
> I have an EXE that calls a COM component in a library application.

> The smart pointer (from the imported dll) is instantiated only when
> required, as calls are infrequent.

> The second time an attempt is made to call CreateInstance, the
> application crashes. This crash though only happens when the
> application is running on a Windows 2000 (SP3) machine. If it is
> running on an XP machine the code works correctly.

> The pointer is a local variable and should clear up once it drops out
> of scope. I have tried both this, and also calling .Release()
> explicitly on the pointer when I am done with it, but neither of these
> methods seems to work.

> What's even more curious is that I have some apps that require they be
> built in VC6, due to 3rd-party components, and they have exactly the
> same behaviour in regards to the smart pointers as the other
> applications that have been built under VC7.

> I've also noticed that the try-catch blocks around the CreateInstance
> method do not seem to catch the error.

> Has anyone had a similar problem, or any ideas on what is going wrong?

> Thanks in advance,

>    Martin



Tue, 29 Nov 2005 00:50:49 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
The code is very simple, at least on the callers side.

myFunction()
{
  try
  {
     MyComLib::IMyIntPtr pMyInt;
     pMyInt.CreateInstance(...)

     pMyInt->SomeMethod();

     //additional processing

  }
  catch (_com_error e)
  {
    //report error
  }

Quote:
}

The first time this function is called everything works.
The second time the app crashes, and the error is not caught as an
exception.

Both apps that have exhibited this behaviour have worked without any
problems on windows XP, but if they run in 2000 they crash.

The COM object that is being called is fairly simple. It opens an xml
document does a quick look-up and returns the result.

I'll try putting a break-point in FinalConstruct when I can get back
at my source code, and thanks for that suggestion, I hadn't thought of
looking there.

What really confuses me though is that the same build works fine on XP
but not on 2K (and we've tested on multiple machines running each OS)
and a couple of other people on my team have looked at the code and
can see nothing wrong with it.

Thanks for your suggestions.

Regards,

   Martin

Quote:

> I doubt there is anything wrong with the smart pointer per se. If your COM
> object crashes the second time it is instantiated, this is strongly
> suggestive of a memory corruption problem.

> What does your COM object do? What resources does it allocate? When and how
> are they freed?

> Can you put a breakpoint in FinalConstruct? Is it reached on the second
> call?



Tue, 29 Nov 2005 06:11:20 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
What is the call stack upon the crash?

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> The code is very simple, at least on the callers side.

> myFunction()
> {
>   try
>   {
>      MyComLib::IMyIntPtr pMyInt;
>      pMyInt.CreateInstance(...)

>      pMyInt->SomeMethod();

>      //additional processing

>   }
>   catch (_com_error e)
>   {
>     //report error
>   }
> }

> The first time this function is called everything works.
> The second time the app crashes, and the error is not caught as an
> exception.

> Both apps that have exhibited this behaviour have worked without any
> problems on windows XP, but if they run in 2000 they crash.

> The COM object that is being called is fairly simple. It opens an xml
> document does a quick look-up and returns the result.

> I'll try putting a break-point in FinalConstruct when I can get back
> at my source code, and thanks for that suggestion, I hadn't thought of
> looking there.

> What really confuses me though is that the same build works fine on XP
> but not on 2K (and we've tested on multiple machines running each OS)
> and a couple of other people on my team have looked at the code and
> can see nothing wrong with it.

> Thanks for your suggestions.

> Regards,

>    Martin


> > I doubt there is anything wrong with the smart pointer per se. If your COM
> > object crashes the second time it is instantiated, this is strongly
> > suggestive of a memory corruption problem.

> > What does your COM object do? What resources does it allocate? When and how
> > are they freed?

> > Can you put a breakpoint in FinalConstruct? Is it reached on the second
> > call?



Tue, 29 Nov 2005 07:11:50 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
Martin,

    Can you try adding another "catch" to your try { } catch() { } block
there to catch something other than the COM error to see if you can trace it
back easily in the de{*filter*}?

Regards,

Joe


Quote:
> The code is very simple, at least on the callers side.

> myFunction()
> {
>   try
>   {
>      MyComLib::IMyIntPtr pMyInt;
>      pMyInt.CreateInstance(...)

>      pMyInt->SomeMethod();

>      //additional processing

>   }
>   catch (_com_error e)
>   {
>     //report error
>   }
> }

> The first time this function is called everything works.
> The second time the app crashes, and the error is not caught as an
> exception.

> Both apps that have exhibited this behaviour have worked without any
> problems on windows XP, but if they run in 2000 they crash.

> The COM object that is being called is fairly simple. It opens an xml
> document does a quick look-up and returns the result.

> I'll try putting a break-point in FinalConstruct when I can get back
> at my source code, and thanks for that suggestion, I hadn't thought of
> looking there.

> What really confuses me though is that the same build works fine on XP
> but not on 2K (and we've tested on multiple machines running each OS)
> and a couple of other people on my team have looked at the code and
> can see nothing wrong with it.

> Thanks for your suggestions.

> Regards,

>    Martin




- Show quoted text -

Quote:
> > I doubt there is anything wrong with the smart pointer per se. If your
COM
> > object crashes the second time it is instantiated, this is strongly
> > suggestive of a memory corruption problem.

> > What does your COM object do? What resources does it allocate? When and
how
> > are they freed?

> > Can you put a breakpoint in FinalConstruct? Is it reached on the second
> > call?



Tue, 29 Nov 2005 13:28:59 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
That is another problem.

Business constraints mean that I don't have a 2000 machine with a
development envrionment, and I am unlikely to get one anytime soon.
The most I can do is run a debug viewer.

Is there anyway I can determine the call stack using just that?

Quote:

> What is the call stack upon the crash?

> --
> =========================
> ============
> Alexander Nickolov
> Microsoft MVP [VC], MCSD

> MVP VC FAQ: http://www.mvps.org/vcfaq
> =========================
> ============

<snip>


Tue, 29 Nov 2005 15:30:40 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
You can get it from a Dr Watson log if one is generated.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD

MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

Quote:

> That is another problem.

> Business constraints mean that I don't have a 2000 machine with a
> development envrionment, and I am unlikely to get one anytime soon.
> The most I can do is run a debug viewer.

> Is there anyway I can determine the call stack using just that?


> > What is the call stack upon the crash?

> > --
> > =========================
> > ============
> > Alexander Nickolov
> > Microsoft MVP [VC], MCSD

> > MVP VC FAQ: http://www.mvps.org/vcfaq
> > =========================
> > ============

> <snip>



Wed, 30 Nov 2005 01:19:57 GMT  
 Smart Pointers Crash in Windows 2000 but not in Windows XP
I have tried adding a catch (...), but this is never entered either.

I am strating to suspect it might be the component I am calling. I
have the same type of usage for another component that has no problems
being re-created.

Since both components are fairly simple the only thing different about
them is that the one that crashes uses the MS XML parser.

I still don't understand why this is only happening on 2k and not XP.

Unfortunatly I don't have time to hunt this down at the moment... too
many other things to do. I have a work-around... which is to create
the pointer as a global variable and only CreateInstance once. That
works without problems, but but I don' belive that is good practice,
it will have to do for the moment though.

Thanks for everyone's help.

Regards,

    Martin

Quote:

> Martin,

>     Can you try adding another "catch" to your try { } catch() { } block
> there to catch something other than the COM error to see if you can trace it
> back easily in the de{*filter*}?

> Regards,

> Joe



> > The code is very simple, at least on the callers side.

> > myFunction()
> > {
> >   try
> >   {
> >      MyComLib::IMyIntPtr pMyInt;
> >      pMyInt.CreateInstance(...)

> >      pMyInt->SomeMethod();

> >      //additional processing

> >   }
> >   catch (_com_error e)
> >   {
> >     //report error
> >   }
> > }

<snip>


Fri, 02 Dec 2005 20:03:37 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. VC++ / MFC application runs on WinNT but crashes on Windows XP / Windows 2000

2. Visual C++ Runtime error in Windows XP, but not in Windows 2000

3. How can I lock keyboard and mouse on Windows 9X and Windows NT/2000/XP

4. Ann: Live Chat on VenturCom Boot-NIC - Windows 2000/XP/XP Embedded Diskless Network Boot

5. windows 2000 pro or windows 2000 server?

6. DAO problems using windows XP and access 2000

7. Windows 2000, ADO 2.5 crashed my development!!!

8. CFileDialog causes Windows 2000 crash

9. CFileDialog in Windows 2000 crashes

10. COM in Windows NT 4 vs. Windows 2000

11. Is programming windows 98 the same as programming windows 2000

12. Porting Windows 2000 program to windows 98

 

 
Powered by phpBB® Forum Software