I am "reawakening" this issue as a new thread because this started two days ago and since I had nothing new to add at that immediate time I feel that it may have "fallen off of the map", so to speak. So here it is again, in summary. The command Code: PDir C:\Windows\winsxs\* /A-D /S /(-128.128fn zc dy/m/d th:m:s fp) >AFile.txt cause(d) my copy of Take Command, TCC to "silently" crash; no error message, no dialog box, nothing at all visible; rather the TCC window where I had entered said command just "disappeared" from the screen. However, it turns out the was a ".gpf" file in my "C:\users/myuserid/AppData/Local.JPSoft" directory; I just didn't notice it initially (probably my bad eyes again as usual). So, after several hours of work, I was able to isolate the single line in TCC.ini that was causing TCC to consistently GPF (consistently because every time, absolutely no exceptions, that I start TCC with this line in the TCC.ini file and run the above-listed command, it (silently) GPF's. Without this single line, absolutely no problem. So what is this single line? Simple: NTFSDescriptions=Yes And, as I said there is (or maybe are is a better word because I've been renaming each of them as they are generated and there are now 23 of them as I write this "note") .gpf files in my ".../AppData/Local/JPSoft" directory. The contents of just one of said .gpf files is: TCC 12.11.76 Module=D:\Program Files\JPSoft\TCMD12BuildLast\TakeCmd.dll Address=1000637A Exception=C0000005 EAX=0D430D88 EBX=7F4F0008 ECX=0D430D88 EDX=029A03E0 ESI=029AC760 EDI=00010000 EBP=01706A60 ESP=016FA9F0 CS=0000001B DS=00000023 ES=00000023 SS=00000023 Flags=00010206 Stack: 1 : TakeCmd.dll 00000001:0000537a 2 : TakeCmd.dll 00000001:0000ceb6 3 : TakeCmd.dll 00000001:0000a85e (The contents of all of the other .GPF files are similar except for explicit address(es).) So, in effort to "isolate" the line that was "causing" the GPF, I followed the following procedure. First, I split the file TCMD.ini into 4 individual "sections", "[PopupFont]", "[4NT]", "[Font]", "[TakeCommand]", and tried the given "PDir" command with a TCC session started using a TCMD.ini file consisting of one, and only one, of those complete "sections". The only TCC session that "crashed" in this configuration was the TCC session that was using the TCMD.ini file containing the "[TakeCommand]" section, and only the "[TakeCommand]" section. So I then essentially did a "binary" search. I "cut" out the second half of the file (again, the TCC.ini containing only the "[TakeCommand]" section), tested it, not bomb, added back one quarter of what I had cut out, tested it, if bombed, cut out the "last" 1/2 of the quarter (or 1/8th) of the file, if didn't bomb, cut out the "first" 1/8 of the file in the quarter that had been originally cut, if bombed, cut out the "last" 1/2 of the the 1/8th (or 1/16th of the file) that had been added...; and I repeated this sequence over and over and over until I had it (each iteration cutting and/or restoring fewer and fewer lines) down to only 1 line. And finally, again after several hours of doing this (each individual test in the sequence took me between 5 and 10 minutes), I found that the line I reported caused the TCC session to "silently" GPF if present, and the "PDir" command successfully ran to completion if absent. As final test(s) to "confirm" my results, executing the "PDir" command with the original "total" TCC.ini file (containing all four "sections" and all lines in each "section") caused a GPF, executing the "PDir" command with the original "total" TCC.ini file minus the "NTFSDescriptions=Yes" line caused the "PDir" command to run to completion without a GPF. And I executed the last two tests 4 or 5 times with always exactly the same results (i. e., it was totally and completely repeatable in all respects). I have to say that, in all honestly, I don't really particularly care at this point in time whether or not anyone else in the world can repeat this problem, and that is because, for me, running without the "NTFSDescriptions" line (which I don't need anyway since I don't use NTFS "Descriptions") is not at all an issue. However, when I was a programmer type for about 30 years, I would want to know about any "crashes" that occurred in any of the programs that I wrote; and I am sort of assuming that the same is true for Rex.