Consistent crashes with error -1073741819 (0xC0000005)

Consistent crashes with error -1073741819 (0xC0000005)

I'm trying to use Inspector XE 2013 to track down a data race, but at various points in my application, Inspector exits with what looks like the exception code for an access violation. I'm running it inside Visual Studio 2010, and the application is compiled with Visual Studio 2010.

If I start the application without analysis and later enable it, I find that Inspector will either hang my application (CPU usage drops to 0, no changes in memory usage after half an hour) or exit with the error code, as mentioned above.

Looking in tc_application.log, I can see this:

    <msg id='101' source='ccrt'>
        <type>INTERNAL</type>
        <severity>ERROR</severity>
        <timestamp>Mon Feb 25 13:56:27 2013</timestamp>
        <!-- RWL requester type must be specified for TC_LOCK_RWLOCK -->
    </msg>
    <msg id='102' source='ccrt'>
        <type>INTERNAL</type>
        <severity>ERROR</severity>
        <timestamp>Mon Feb 25 13:56:27 2013</timestamp>
        <!-- Threadchecker or PIN generated an exception: Exception Code: RECEIVED_ACCESS_FAULT. Exception Address = 0x5700a3bb. Access Type: READ. Access Address = 0x0 -->
    </msg>

Is there any way to prevent this from happening?

AnhangGröße
Herunterladen tc-application.log31.55 KB
3 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

The bug you encountered has been found recently in our internal testing.   It is caused by a mishandling of InitializeCriticalSectionEx in the tool when the CRITICAL_SECTION in question happens to be at the same address as a previously intialized SRW lock and, therefore, it gets misinterpreted on acquire as an SRW lock.  

The best solution will be to get you an updated version of Inspector that has this bug fixed (which doesn't exist at present).   In the meantime, a workaround would be to refrain, if possible, from using InitializeCriticalSectionEx and instead use one of the other intialization routines.   This may not be possible considering that the initialization in question may not have actually originated from your code but without an update, it is the best advice I can give.

I apologize for the inconvenience this has caused you.  

I think we have a fix for this but we would like to verify it on your code if possible.   Do you have a sample you could send me where the failure is manifest?

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen