Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

PDir causing Take Command/TCC to crash...

May
855
0
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.
 
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).

Or perhaps because I told you, wrongly, to look in the program directory....

I haven't been able to reproduce this. But looking over your .INI file, I get the sense that you may be using x64 Windows?
 
On Tue, 04 Oct 2011 13:45:14 -0400, mathewsdw <>
wrote Re [Support-t-3259] PDir causing Take Command/TCC to crash...:


>So what is this single line? Simple:
>
>NTFSDescriptions=Yes

You mentioned previously that you don't need NTFSDescriptions. Why
not just set it to NO?
 
Or perhaps because I told you, wrongly, to look in the program directory....

I haven't been able to reproduce this. But looking over your .INI file, I get the sense that you may be using x64 Windows?
Simply put, Charles, no. Plain-old-32-bit Windows.
 
On Tue, 04 Oct 2011 13:45:14 -0400, mathewsdw <>
wrote Re [Support-t-3259] PDir causing Take Command/TCC to crash...:
You mentioned previously that you don't need NTFSDescriptions. Why
not just set it to NO?
Caesar, while that just might work, I didn't do that because my effort was to isolate the line that was causing the GPF, that and only that. And, simply put, because it works fine without that line, I have no incentive whatsoever to take the time to do more experimentation by putting that line back in the file and setting its value to "NO".
 
Still not reproducible here, with or without NTFSDescriptions=Yes.

The stack trace shows that your system ran out of memory.
Rex, since, as I said previously, I have an effective "workaround" and I don't have the ability to decode "stack traces" in general at this point in time (particularly since I've been effectively retired for more than ten years) and anyway don't have either the source code or the compiler listings to check the "stack trace" against, there is absolutely no way I can or would "dispute" your finding(s) on that issue. However (yes, there is a "however"), that absolutely does not, in and of itself, explain why that particular "PDir" command successfully runs to completion if that line is not in the .ini file and (silently) GPF's if that line is in the .ini file, and I just repeated the test yet one more time before starting this reply and that absolutely still is the case for me. I would also have to add, "why is no other application or TCC session not executing that particular command not having that particular problem?" I have no more to say on this subject unless you have something more you would like me to say or you have a question that I can answer. As the saying goes, "I am at your service".
 

Similar threads

Back
Top