v26 exception log gone crazy

[vefatica]

I knew nothing of this until Windows popped up a low disk space warning.

c:\programdata\jp software\take command 26> d t*
2021-08-14  12:09 422,797,849,306  tcc.exception.log

The logging started like this:

[2021/08/14 11:23:15.760] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO
[2021/08/14 11:23:15.760] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO
[2021/08/14 11:23:15.760] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO

and ended like this (400+ GB later):

[2021/08/14 12:09:24.574] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO
[2021/08/14 12:09:24.797] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO
[2021/08/14 12:09:24.976] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FFD85B42157 - INT_DIVIDE_BY_ZERO

I re-ran all of today's commands that might have involved v26 and none caused any further logging.

Shouldn't TCC terminate or let me know when something like this happens?

Any ideas?

 

[vefatica]

Those log lines are 127 Unicode characters long (254 bytes). That's 1664558461 lines in 44 minutes, or 630514 lines per second. I would have thought that impossible.

 

[Charles Dye]

Mine looks like this:

C:\ProgramData\JP Software\Take Command 26>dir

 Volume in drive C is Windows      Serial number is 4408:76e6
 Directory of  C:\ProgramData\JP Software\Take Command 26\*

12/15/2020  13:16         <DIR>    .
12/15/2020  13:16         <DIR>    ..
11/17/2020   8:41         <DIR>    updates
12/15/2020  13:18           1,002  TCC.exception.log
               1,002 bytes in 1 file and 3 dirs    4,096 bytes allocated
     152,610,078,720 bytes free

C:\ProgramData\JP Software\Take Command 26>type TCC.exception.log
[2020/12/15 12:16:38.672] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FF931DD1000 - ACCESS_VIOLAT
ION
[2020/12/15 12:18:27.442] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FF931511000 - ACCESS_VIOLAT
ION
[2020/12/15 12:18:27.442] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FF931511000 - ACCESS_VIOLAT
ION
[2020/12/15 12:18:35.381] D:\TakeCommand26\tcc\ntinit.cpp:364 wmain()  SEH Exception: 0x00007FF931511000 - ACCESS_VIOLAT
ION

C:\ProgramData\JP Software\Take Command 26>

I'll bet I was working on a plugin that day. And doing something wrong.

 

[vefatica]

All I did today that involved TCCv26 were variations of this theme.

do i=24 to 28 ( d:\tc%i\tcc.exe /c eval_alias 2+2 ^> clip: & echo ^%@clip[0] )

 

[rconn]

The exception logging is done in a separate (very minimal) thread that has no communication with the other TCC threads.

SEH exception logging is 99.99% plugins or apps that are injecting code into TCC. Exceptions that occur in TCC code are handled differently (not via SEH).

 

[vefatica]

Hmmm! The only DLLs attached to TCCv26, other than system DLLs and DLLs from JPSoft, are my own plugins, which don't use SEH or do any injecting.

I don't suppose the OS knows anything about TCC's exception log. Is there any way the thread you spoke of can get "stuck" and log over 600,000 messages per second for 44 minutes?

 

[rconn]

TCC is doing the SEH for plugins (always has).

There is no way the thread can get "stuck"; it is called by Windows when there's an exception. (Whether Windows can get stuck is something you'll have to ask Microsoft.)