How to catch error happening AFTER the code / application

[LeanA]

Hi all!



I am using a DLL which I am not sure if has some issues. The problem is that it always causes my application to crash right AFTER the code / application.


However, I can properly use all its function while inside the code.



What I want to do is to probably make the error 'silent' or seemingly not happening. The problem is, I can't put this on try-catch because it happens AFTER the code.



Has anyone any idea what I need to do?



Thank you!

[GCDEF]

What do you mean cause the application to crash after the application?

Have you tried the debugger?

[Paul McKenzie]

Hi all!



I am using a DLL which I am not sure if has some issues.

What is the name of this DLL? Have you contacted the persons responsible for creating the DLL?

The problem is that it always causes my application to crash right AFTER the code / application.

Maybe it is your application that is faulty or doing something illegal, and not the DLL.

However, I can properly use all its function while inside the code.

As any experienced C++ programmer would tell you, just because it crashes at some point doesn't mean that is where the problem started.

Again, you could have been using the code incorrectly, and then the crash occurs due to your improper usage.

What I want to do is to probably make the error 'silent' or seemingly not happening. The problem is, I can't put this on try-catch because it happens AFTER the code.

You should be determining exactly why the code crashes, and not create band-aid "solutions" that do not really fix the problem.

Regards,

Paul McKenzie

[LeanA]

Hi all,

The dll I am using is from Microsoft. I already reported it to the Microsoft connect.

I am about 80% sure that the dll is what is wrong. I tried using it in 2 languages: C# and C++. Both languages error in exactly the SAME way.

I am also sure that I am using the DLL properly in C++, because I have used a similar DLL that requires the same code. This DLL however, is for a different function.

I would like to know if there is a way to make the error in the end 'silent'?

Thanks

[VictorN]

And, if it is not a big secret, - which one from hundreds or thousands of MS DLLs do you mean?

And again: you haven't provided enough info yet about how and where it crashed

[LeanA]

Hi all:



Here is the code in order to provide more information:

#include "stdafx.h"
#include "ATLComTime.h"
#import "TSCore.dll" named_guids
#import "tsmediaapi.dll" named_guids
using namespace TsMediaLib;

int _tmain(int argc, _TCHAR* argv[])
{
      ::CoInitialize(NULL);
      IPxeAuthClassPtr pxecls;
      pxecls.CreateInstance(CLSID_PxeAuthClass);
     
      VARIANT varDate;
      VariantInit(&varDate);
      COleDateTime mytime(1996,1,1,0,0,0);
      varDate = _variant_t(mytime, VT_DATE);
      _bstr_t name = "ab40c4ab-7e74-4740-9a09-e999e876edaa";
 
      _variant_t out;
      out = pxecls->CreateIdentity(name,name,name,&varDate,&varDate);

      VariantClear(&varDate);

pxecls.Release();

      ::CoUninitialize();

      cout << “END” << endl;

}

It reaches the "END" and then crashes with error:



TSMediaInterop.vshost.exe: Managed' has exited with code -1073741819 (0xc0000005).



Here is also a link to the DLL we are using (TsMediaApi.dll): http://msdn.microsoft.com/en-us/library/cc142946.aspx



Thank you!

[itsmeandnobodyelse]

error code 0xc0000005 (access violation) is pointer error. when it occurs after unloading the dll it means that releasing of resources crashes what can happen if you didn't call a necessary initialisation routine or function.

You can do the following:

- add a return statement to your _tmain function (what is bad habit if it is missing)
- set a breakpoint to that return statement
- change your debug - exceptions - win32 settings so that the debugger stops
immediately before the access violation (0xc0000005) exception was thrown

The default is that it first tries to find a handler (in your case there is none) and that is why you don't get a break where the wrong pointer actualy was used.

[LeanA]

Hi itsmeandnobodyelse, thanks for replying.

I just tried what you suggested (add a return as well as the debug). The same error still occurs.

I was able to stop at the return breakpoint and managed to continue from that point. Right after that, when the code finishes, it crashes. The error said by Visual studio is still the same:

First-chance exception at 0x67e9bed0 in TSMediaC++.exe: 0xC0000005: Access violation reading location 0x0229feb0.

I really think that the DLL is what is wrong here, as I also tried it with C# but using a "Void" return type. May I ask if there is a way to make the error 'silent' or something?

Thank you!

[itsmeandnobodyelse]

Hi itsmeandnobodyelse, thanks for replying.

I just tried what you suggested (add a return as well as the debug). The same error still occurs.

I was able to stop at the return breakpoint and managed to continue from that point. Right after that, when the code finishes, it crashes. The error said by Visual studio is still the same:

First-chance exception at 0x67e9bed0 in TSMediaC++.exe: 0xC0000005: Access violation reading location 0x0229feb0.

I really think that the DLL is what is wrong here, as I also tried it with C# but using a "Void" return type. May I ask if there is a way to make the error 'silent' or something?

Thank you!

Ok, it is clear that your last action would not solve the error cause it only improves your ability to debug.

When it crashes are you able to debug from there? Do you get a popup where you can use a 'Retry' button or can retrieve additional information? The 0x0229feb0 is the wrong (pointer) location where it dies. If you come to the return statement and the exception was NOT already thrown, it means that the dll (and your prog) has worked until that but when the prog (and the dll) wants to free its resources it crashes.

I would guess it is because of the following statements:

VariantClear(&varDate);
pxecls.Release();

With these statements you were freeing resources which probably were still in use in a thread created by the dll. When you close the program the thread tries to free additional resources but dies because you freed the resources of varDate and/or pxecls.

You can check that guess by commenting those statements and try again.

If I am right you would need to call some 'cleaning' functions before you can stop your main program.

[Paul McKenzie]

Hi all,

The dll I am using is from Microsoft. I already reported it to the Microsoft connect.

I am about 80% sure that the dll is what is wrong. I tried using it in 2 languages: C# and C++. Both languages error in exactly the SAME way.

If you use the same code, of course you will get the same error.

I am also sure that I am using the DLL properly in C++

First, when posting code, use code tags. The code you posted is unformatted, and is double spaced, making it very hard to read.

Second, whatever you posted contains only a few lines. If a very simple program like that can break a DLL created by Microsoft, then hundreds, probably thousands of programmers would have noticed and reported it. Therefore, the problem is more than likely your code, not the DLL.

Regards,

Paul McKenzie

[LeanA]

Hello all thanks for replying,

Will try the 'cleaning' functions and get back to you.

Actually, I have seen some threads similar to the error I am experiencing with the same DLL. Microsoft said they will escalate it but no replies yet.

I have also reported it to Microsoft connect, but no replies yet also.

Thank you

[LeanA]

Hi all, thanks for replying


@itsmeandnobodyelse

I tried commenting out the ones you mentioned, however, the error still occurs.


I added 0xC0000005 to the Exception in Debug->Exception. Since I added the 0xC0000005 Exception to Debug->Exception, I start to Break at "CoUninitialize" instead of the end of the program.

If the CoUnitilize is available, the Debugger breakpoints there. However, if the CoUnitialize is commented out, First-Chance exception occurs instead on this code block, specifically in __crtExitProcess(code):

#endif /* CRTDLL */
   }
#endif /* _DEBUG */

  }
  /* return to OS or to caller */

  __FINALLY
   if (retcaller)
    _unlockexit();  /* unlock the exit code path */
  __END_TRY_FINALLY
  if (retcaller)
   return;


  _C_Exit_Done = TRUE;

  _unlockexit();  /* unlock the exit code path */

  __crtExitProcess(code);
}

The file that it errors to is called "crt0dat.c".


I tried adding try-catch but it does not catch the error. I think this is because the error happens outside the code, going out of the try-catch.

Actually, even if I don't use its function "CreateIdentity", just initializing PxeAuthClass makes the error. This is both for C++ and C#.


Thank you

PS. Sorry for not using CodeBlocks / Quotes. For some reason, the option does not appear when I reply.

[Paul McKenzie]

PS. Sorry for not using CodeBlocks / Quotes. For some reason, the option does not appear when I reply.

To use code tags:
[code] Your code goes here [/code]

Please re-edit your message to place the proper code tags, and get rid of the annoying double spacing.

Regards,

Paul McKenzie

[itsmeandnobodyelse]

According to the docs

A thread must call CoUninitialize once for each successful call it has made to CoInitializeEx

CoUninitialize only may be called for a call to CoInitializeEx.

So, I would try to call CoInitializeEx and explicitly pass the needed threading model.

[ADSOFT]

I would first comment out these functions:

_variant_t out;

out = pxecls->CreateIdentity(name,name,name,&varDate,&varDate);

VariantClear(&varDate);

That would tell me if I'm using pxecls properly.

Then I would try:

 pxecls->CreateIdentity(name,name,name,&varDate,&varDate);

by itself

then add the out code.


http://systemscenter.ru/sccm_sdk.en/...9dadff9911.htm