1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

PDir causing Take Command/TCC to crash...

Discussion in 'Support' started by mathewsdw, Oct 4, 2011.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    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.
     
  2. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,312
    Likes Received:
    39
    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?
     
  3. CaesarR

    Joined:
    Nov 3, 2010
    Messages:
    9
    Likes Received:
    0
    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?
     
  4. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Simply put, Charles, no. Plain-old-32-bit Windows.
     
  5. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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".
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    Still not reproducible here, with or without NTFSDescriptions=Yes.

    The stack trace shows that your system ran out of memory.
     
  7. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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".
     

Share This Page