set CR_INST_AUTO_THREAD_HANDLERS and get ATLASSERT(m_ThreadExceptionHandlers.size()==0);

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable crashrpt's functionality in a project with one major flag: 
CR_INST_AUTO_THREAD_HANDLERS
2. Run project's EXE and close it.

What is the expected output? What do you see instead?
Do not see any MessageBoxes/Asserts.
But You will see the messagebox which is reporting that 
m_ThreadExceptionHandlers.size() !=0 when it should be equal.
This assert is come from CrashHandler.cpp from line 743.

What version of CrashRpt are you using? the latest 1.4.2

What is your version of Visual Studio? 2010 pro.

What is your version of Windows operating system? WinXP SP3 eng.

Please provide any additional information below.
This described phantom project - could be any from those you have on your hand. 
The only major note - it should somewhere in it's core code to create a few 
threads - in automatic mode. I mean - not the code of projects itself should do 
that = as you described it in your web's tutorial. NO - there is no any visible 
"DWORD WINAPI ThreadProc(LPVOID lpParam)" function in available code. But in 
some thirdparty objects/classes this code should exist In cde which I(you) 
can't attach/fix/re-code. That's why my main projects' code does not know 
anything about how many - where - how - for which period of time - the threads 
were created and started. That's why I've used CR_INST_AUTO_THREAD_HANDLERS 
flag in MY projects' code. And that's why I expect that 'crashrpt' tool by 
himself should deal correctly with such situation. And I am waiting that it 
will call by himself in all autocreated threads corresponding function 
crUninstallFromCurrentThread(). But for today - looks like it was not 
implemented at all...

Definitely it's a bug.

So - which first attempt to fix it I can do? Simply comment out line with 
ATLASSERT?

Original issue reported on code.google.com by graphEle...@gmail.com on 9 Jul 2013 at 10:51

[GoogleCodeExporter]

No, this is not a bug. You can look at CrashRpt.cpp line 963. Thread exception 
handlers are uninstalled, when thread is being detached. It seems that your 
third-party thread is detached after you call crUninstall().

Original comment by zexspect...@gmail.com on 9 Jul 2013 at 12:24

• Changed state: Reviewed

[GoogleCodeExporter]

Probably, you should just ignore the assert. Or use Release version of CrashRpt.

Original comment by zexspect...@gmail.com on 9 Jul 2013 at 12:24

[GoogleCodeExporter]

Yes - I saw this code - but the case you've mentioned and which is more than 
realistic - third-party thread is detached after you call crUninstall() - also 
should be analyzed and taken into account in Destroy() function for 
CrashHandler.
IMHO it should be more easy - to walk though all threads and to call 
crUnInstall BEFORE any other actions...
rather than simply ignore this case - when not all handlers were uninstalled 
before Destroy() function was called.

P.S. what about exceptions in .NET libraries which can be potentially loaded by 
my app. Can they be intercepted and converted into dumps - like it was done for 
simple C++ and OS exceptions....

Original comment by graphEle...@gmail.com on 9 Jul 2013 at 12:36

[GoogleCodeExporter]

I'm not sure it is easy to uninstall exceptions from all threads. You should 
call the uninstall function _FROM_ the thread where it was installed. I cannot 
call the function from another thread.

I've not tested CrashRpt with .NET apps.

Original comment by zexspect...@gmail.com on 9 Jul 2013 at 12:43

[GoogleCodeExporter]

hmmm... I can't do that: "call the uninstall function _FROM_ the thread where 
it was installed." my friend - because this installation was done in auto-mode 
- by your tool. I mean with CR_INST_AUTO_THREAD_HANDLERS flag enabled your tool 
is installing all handlers by itself - what means that your tool should be able 
also to UNinstall all handlers by itself... IMHO it's a logical sentence. Isn't 
it?

And IN case when this can't be done for some reasons - but i do not understand 
them. 
For ex. some third party libs which are auto-creating a few threads in which 
crashrpt tool is installing its handlers in auto-mode - those libs will be 
detached from the main process's AFTER crUninstall() call - Am I right? But 
this is a correct windows approach. Obviously that dynamically loaded DLLs - 
will be detached only when the main process has exited from its 'int main()' 
function. So in such case your tool should in auto-mode somehow UNinstall all 
handlers by itself.

    // All installed per-thread C++ exception handlers should be uninstalled 
    // using crUninstallFromCurrentThread() before calling Destroy()
    {
        CAutoLock lock(&m_csThreadExceptionHandlers);
        ATLASSERT(m_ThreadExceptionHandlers.size()==0);          
    }
So in which cases this code will work correctly? Only for manual handlers 
setting?
And what potentially can happened - if we will remove at all this code?
IS it a really dangerous situation - when m_ThreadExceptionHandlers.size()!=0?

Original comment by graphEle...@gmail.com on 9 Jul 2013 at 2:06

[GoogleCodeExporter]

Hello! So - what do you think about my previous post?

And in addition I have another question - what about a stacktrace? Can you add 
the possibility to write such special file at dump folder on a par with those 
that are already there? 

Yep - a more interesting info I can find in dump file - but sometimes we can't 
create a dump while the stacktrace can be created. I already faced with such 
cases in my real practice...

Original comment by graphEle...@gmail.com on 10 Jul 2013 at 12:43

[GoogleCodeExporter]

If a third-party thread is created after you call crInstall() and destroyed 
after you call crUninstall(), you'll get the assert message, and I can't fix it 
in CrashRpt. I would not suggest you to ignore the assert, because it may be a 
symptom of some unexpected behavior. I suggest you to install thread exception 
handlers manually.

Original comment by zexspect...@gmail.com on 10 Jul 2013 at 1:45

• Changed state: WontFix

[GoogleCodeExporter]

At first:
you've missed a question about a separate stacktrace file. Can you answer on it?
Or I should open a new issue/wish ticket?

At second:
I don't understand - how I can make a manual per-thread handlers installations 
- IF I don't know in which attached to my app dlls those threads will be 
created.

Just run any exe which you have on your hands and you will see that it will 
load not only those dlls which can be found in the same folder where the main 
app.exe file exists - but many-many others.
So I want to make sure that I can to catch exceptions in any threads which will 
exist at some moment of time - doesn't matter in which attached dlls this 
exception can occur and that's why I've with pleasure have installed crashrpt 
tool with flag CR_INST_AUTO_THREAD_HANDLERS.

And now you want to say to me - that this logiс - is not logical?
Yes - For those threads to which my code has access - it can be done. But we 
are talking about case - when exception can occur in some thirdparty attached 
dll - which code I do not have. Your tool can intercept such exception - and of 
course it shouldn't throw an assert about not all closed handlers.

Original comment by graphEle...@gmail.com on 10 Jul 2013 at 2:51

[GoogleCodeExporter]

I understand that for this particular not-a-bug-but-a-feature record the final 
status was assigned: WontFix - but maybe you can still answer on a few 
questions in my post above?

Original comment by graphEle...@gmail.com on 12 Jul 2013 at 12:23

[GoogleCodeExporter]

Hello, I will be happy to answer your questions here: 
https://code.google.com/p/crashrpt/wiki/CommercialSupport
Bug tracker is not a very convenient place for answering questions.

Original comment by zexspect...@gmail.com on 12 Jul 2013 at 1:05