C0000005 exception unloading plugin?

[vefatica]

I'm running a monitoring script which does "@execarray[a,command | command | command]" every 5 seconds. So I figure TCC is starting over 1000 times an hour. One of my plugins (4console) refuses to load (InitializePlugin returns TRUE, ShutdownPlugin does nothing and returns FALSE). The script ran overnight (several thousand instances of TCC) and this morning I have 15 of these in my reliability history. Any ideas?

Source
TCC

Summary
Stopped working

Date
‎2020-‎09-‎24 11:03

Status
Report sent

Description
Faulting Application Path:    D:\tc26\tcc.exe

Problem signature
Problem Event Name:    BEX64
Application Name:    TCC.EXE
Application Version:    26.2.42.0
Application Timestamp:    5f1cdca6
Fault Module Name:    4threads64.dll_unloaded
Fault Module Version:    0.0.0.0
Fault Module Timestamp:    5e6da034
Exception Offset:    00000000000010a4
Exception Code:    c0000005
Exception Data:    0000000000000008
OS Version:    10.0.18363.2.0.0.256.161
Locale ID:    1033
Additional Information 1:    2264
Additional Information 2:    2264db07e74365624c50317d7b856ae9
Additional Information 3:    875f
Additional Information 4:    875fa2ef9d2bdca96466e8af55d1ae6e

Extra information about the problem
Bucket ID:    2f5ac40bef56d363916f68a12336c9a2 (1256337862349474210)

 

[Charles Dye]

I'm running a monitoring script which does "@execarray[a,command | command | command]" every 5 seconds. So I figure TCC is starting over 1000 times an hour. One of my plugins (4console) refuses to load (InitializePlugin returns TRUE, ShutdownPlugin does nothing and returns FALSE).

I think InitializePlugin() is expected to return 0, and TCC will unload the plugin if it returns nonzero. I've made use of that behavior occasionally to prevent a plugin from loading, though I haven't actually seen it documented anywhere.

 

[vefatica]

I think InitializePlugin() is expected to return 0, and TCC will unload the plugin if it returns nonzero. I've made use of that behavior occasionally to prevent a plugin from loading, though I haven't actually seen it documented anywhere.

That's exactly what I'm doing. Returning TRUE (on purpose) so it won't load (actually so it will be unloaded immediately).

But I don't understand why I get any of these error reports at all or why I get only a handful of them when there are thousands of opportunities.

 

[vefatica]

Well, here's another one ... from a different plugin, one which does not refuse to load. So I figure these are happening when TCC exits and only extremely rarely.

Charles, do you load any plugins? If so, do you have any such reports? Look in ControlPanel\SecurityAndMaintenance ... Maintenance ... ViewReliabilityHistory.

Source
TCC

Summary
Stopped working

Date
‎2020-‎09-‎24 11:38

Status
Report sent

Description
Faulting Application Path:    D:\tc26\tcc.exe

Problem signature
Problem Event Name:    BEX64
Application Name:    TCC.EXE
Application Version:    26.2.42.0
Application Timestamp:    5f1cdca6
Fault Module Name:    4threads64.dll_unloaded
Fault Module Version:    0.0.0.0
Fault Module Timestamp:    5e6da034
Exception Offset:    00000000000010a4
Exception Code:    c0000005
Exception Data:    0000000000000008
OS Version:    10.0.18363.2.0.0.256.161
Locale ID:    1033
Additional Information 1:    2264
Additional Information 2:    2264db07e74365624c50317d7b856ae9
Additional Information 3:    875f
Additional Information 4:    875fa2ef9d2bdca96466e8af55d1ae6e

Extra information about the problem
Bucket ID:    2f5ac40bef56d363916f68a12336c9a2 (1256337862349474210)

 

[Charles Dye]

Well, here's another one ... from a different plugin, one which does not refuse to load. So I figure these are happening when TCC exits and only extremely rarely.

Charles, do you load any plugins? If so, do you have any such reports? Look in ControlPanel\SecurityAndMaintenance ... Maintenance ... ViewReliabilityHistory.

That would be under Application Failures, right? I'm not seeing anything like that. But I'm not opening huge numbers of TCC instances, either, so I guess that doesn't prove anything.

 

[vefatica]

Yes. If you click on one of the days of weeks in the graphic, the failures and listed below. They're pulled from the Application Event Log (event ID 1000).

I have about 650 of them going back to 9/2019, involving TCC v25 and 25 and all the plugins I have. That means it has nothing to do with refusing to load. And given the bizarre things I do, they're pretty rare.

i just managed to get two of them but to do so I had to do this about 10 times.

do i=1 to 1000 (echo foo | findstr bar | grep bar | findstr g )

I reckon that's 30,000 (or so) pipe instances of TCC.

Here's one of the two, dug out of the event log with the ancient DUMPEL.EXE (NT4 Resource Kit?).

9/24/2020       20:31:49        Faulting application name: TCC.EXE, version: 26.2.42.0, time stamp: 0x5f1cdca6  Faulting module name: 4threads64.dll_unloaded, version: 0.0.0.0, time stamp: 0x5f6cd5b5  Exception code: 0xc0000005  Fault offset: 0x0000000000001101  Faulting process id: 0x21c0  Faulting application start time: 0x01d692d341794e97  Faulting application path: D:\tc26\TCC.EXE  Faulting module path: 4threads64.dll  Report Id: c53a3508-a242-4a91-a417-a4821eae6df5  Faulting package full name: ?  Faulting package-relative application ID: ?

 

[rconn]

Not much I can do to debug that, given that the crash is occurring inside your plugin dll, not TCC.

Are you replacing the default exception handler? Normally TCC would trap an exception in a plugin.