It looks like IF ISDIR \\myserver\c$ ... also works in old and current TCC.

This seems to cover it. Thanks!

Well, I didn't RTM back in v16, and it worked, even if it wasn't supported. :-) Obviously I can't complain about something not working that was unsupported!

In TCC version 16, @ready[\\myserver\c$] returned 1 if myserver could be reached on the network, even if it hadn't been authenticated yet. Now in TCC version 28 (the latest), it returns, "The parameter is incorrect." Why the change, but more importantly, is there a way I can query if a UNC...

I've been using the gsudo -i Medium tcc.exe method without issue. But that does look like an elegant solution.

Thanks, Rex. I installed the latest TCC and it doesn't crash. I'll have to look into how to contact Carbon Black.

I had Symantec Endpoint Protection and Deep Instinct installed, and we were told that we could improve our system performance and still be using company-approved tools by having those two uninstalled and instead, installing Carbon Black Endpoint. As soon as I did that and restarted the system...

Rex mostly hit on the solution. It turns out I had installed in two folders, so when I ran TCC, it ran from one location, while when I ran TCMD, it ran from the other. Only the first one had all of my TCSTART.BTM, alias and function definition files. I've cleaned up my installations so...

The aliases that are loaded through the tcstart.btm processes aren't getting loaded. I just assumed it wasn't being run. I guess I'll throw some debugging into the tcstart and see what I can find out.

I use tcc.exe about 99.99% of the time. But for the infrequent time when I want to start up TCMD, I noticed that it doesn't seem to run my TCSTART.btm file like a TCC window does. Is this expected? If not, is there an equivalent (say, TCMD.btm)? Note: I'm using TCC 16.03.55 x64 Windows...

My AV is Symantec Endpoint Protection. I had auto virus definitions turned off (don't remember why). Turning it back on, then getting the updates, solved my issue. Hope this helps.

It seems that my virus definitions being out of date may have caused the issue. I ran a definition update that apparently hadn't happened since July, ran a scan, no issues were found, but now the tcc copy works properly. So thanks for pointing me in that general direction, which ultimately...

It seems that my virus definitions being out of date may have caused the issue. I ran a definition update that apparently hadn't happened since July, ran a scan, no issues were found, but now the tcc copy works properly. So thanks for pointing me in that general direction, which ultimately...

One quick additional data point: I executed the exact same command as the one that crashes, only adding in the /n switch so that it doesn't actually do the copy, and it ran all of the way through, reporting all of the files that would be copied if the copy were to take place, and didn't crash...

So it sounds like the most recent Windows 10 patches may have broken it. Any more data points from other users out there who have the latest Windows 10 patches and maybe the most recent version of TCC?