TCC crashing on Windows 10 final release(?)

[jadaml]

I do not know how many of you had the opportunity to install the latest Windows 10, that was (supposedly) launched on July 29 but since not all users gets it immediately, I don't know if I count on that.
Searching on the forum did not revealed if it is crashing for others.

After I did an upgrade to Win10 from Win7 (not a clean install) and no matter how it is launched, but TCC.exe always crashing. (TCMD stays alive, and could do things like upgrade, but TCC in it will crash.)
I can't find any error report, or crash dump to check for the cause of the crash.

TCC before crash, prints the Windows version, and it reports version 6.3.10240.
CMD reports 10.0.10240.
WinVer reports it like 10.0 Build: 10240.
I read in another thread, that version differences was a change in the API, as a backward compatibility feature perhaps?

 

[rconn]

Not reproducible here.

What version of Take Command / TCC are you running?

 

[jadaml]

Ah, yes, I forgot to mention: It's 18.00.29 x64

 

[rconn]

What exactly do you mean by "TCC.exe always crashing" -- do you see a Windows exception popup, or does TCC just go away?

If the crash is in TCC code, it will generate a TCC.EXCEPTION.LOG file (in the installation directory if it's writeable, otherwise in "c:\ProgramData\JP Software\Take Command x64 18.0\").

If the crash is in Windows code, you'll get the exception popup.

If the crash is in third-party code that is being injected into the TCC process, you may or may not get anything.

What happens if you start a CMD process (not in a TCMD tab window) and launch TCC from there? Try starting TCC without any TCMD.INI, TCSTART or plugins (i.e., "TCC /I")?

 

[jadaml]

What exactly do you mean by "TCC.exe always crashing" -- do you see a Windows exception popup, or does TCC just go away?

The "TCC Stopped working" dialog appears. It offers to debug it, but it would be little of use.

If the crash is in TCC code, it will generate a TCC.EXCEPTION.LOG file (in the installation directory if it's writeable, otherwise in "c:\ProgramData\JP Software\Take Command x64 18.0\").

I did saw a TCC.EXCEPTION.LOG file, but it was empty (beside of the BOM character) I have installed Take Command to D:\Programs\[...] and the log file appears in there. It was working like that in Windows 7.

If the crash is in Windows code, you'll get the exception popup.
If the crash is in third-party code that is being injected into the TCC process, you may or may not get anything.

Then it is the prior.

What happens if you start a CMD process (not in a TCMD tab window) and launch TCC from there? Try starting TCC without any TCMD.INI, TCSTART or plugins (i.e., "TCC /I")?

Starting TCC from CMD crashes (the way as mentioned above). TCC /I crashes too. I have already removed the plugins (renamed the plugins folder to plugins.bak), and now moved the TCMD.INI TCSTART files out the way, and still crashes.

 

[rconn]

Then I need the details from the Windows popup (such as the exception address, module, etc.).

 

[jadaml]

Uh... what details?
The window appears is what is shown in the attachment. (I try to use the new feature to easily switch to English, and create a screen shot of it later, so you can actually read it.)

 

[jadaml]

Aha! Better yet. Debugging TCC (I prefer not to) reveals an exception number of: 0xC0000005 (I hope I got the number of zeros right.)
I have attached a screen shot of this window as well.

 

[jadaml]

Did my last post helped to narrow the issue down? I still cannot run TCC and I would like to use it.
I have just updated my Take Command but it still crashing, and the log is still empty.

I am really the only one experiencing this?

 

[rconn]

Aha! Better yet. Debugging TCC (I prefer not to) reveals an exception number of: 0xC0000005 (I hope I got the number of zeros right.)
I have attached a screen shot of this window as well.

The 0xC0000005 isn't relevant; what is important is the exception address (0x0007FFD3D682080). That address isn't in the normal TCC process address space - something else is injecting a dll into the TCC process, and that's where it's crashing. (Which is why you're not getting anything in TCC.Exception.log.)

There's nothing I can do to debug that without access to your system. I'd suggest temporarily disabling things like antivirus, screen managers, etc. to isolate what's doing it.

 

[rconn]

I am really the only one experiencing this?

I don't know about that, but you're the only one reporting it. Which strongly suggests a system-specific problem.

 

[jadaml]

The 0xC0000005 isn't relevant; what is important is the exception address (0x0007FFD3D682080). That address isn't in the normal TCC process address space - something else is injecting a dll into the TCC process, and that's where it's crashing. (Which is why you're not getting anything in TCC.Exception.log.)

There's nothing I can do to debug that without access to your system. I'd suggest temporarily disabling things like antivirus, screen managers, etc. to isolate what's doing it.

I see. Well since it worked before I've upgraded, I must believe it cannot be anything that was installed before, like AntiVirus software, but I don't know. Thank for the tip, and I'll try to figure out what is happening, what injects it's DLL that cause the issue, and write back when I have find it.

 

[jadaml]

That was quick.
I realized that I have installed clink with chocolatey which have changed the command processor autorun registry entry to run and inject clink. Removing that entry fixed my issue. I've installed clink before the upgrade, and it never posed an issue before with Take Command.

It is working now, and I'll figure a way to co-op with this, since I only need that for CMD, and not TCC.