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

PDIR command causes GPF

Discussion in 'Support' started by Steve Fabian, Aug 13, 2010.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    The command below, which works in TCC V9, causes consistent GPFs in V10 and
    later:

    *pdir/s/nej/ou/a:/(a fpn) f:\ > dl.f

    F: is a hard drive. File dl.f is created on a different drive (C:\save).
    When the GPF occurs, the output file is terminated after the second of the
    lines below (the 150648th line of the file):

    ___A________I F:\PICTURES\200805\28150444.JPG
    _H_A________I F:\PICTURES\200805\DESCRIPT.ION
    ___A_________ F:\PICTURES\200806\02083224.JPG
    ___A________I F:\PICTURES\200806\02083232.JPG

    V09 records 181822 files. Dropping the /Ne flag and redirecting errors still
    GPFs, with empty error file.

    GPF (with lots of plugins loaded):

    TCC 11.00.52
    Module=F:\JPSOFT\I11\TakeCmd.dll
    Address=10005CD7
    Exception=C0000005
    EAX=00000000 EBX=00000000 ECX=023D8318 EDX=006B0063
    ESI=00000000 EDI=00D70676 EBP=00D746A4 ESP=00D6C64C
    CS=0000001B DS=00000023 ES=00000023 SS=00000023
    Flags=00010246

    Stack:
    1 : TakeCmd.dll 0001:00004cd7
    2 : TakeCmd.dll 0001:0000ba86
    3 : TakeCmd.dll 0001:00009671

    GPF (with all plugins unloaded):

    TCC 11.00.52
    Module=F:\JPSOFT\I11\TakeCmd.dll
    Address=10005CD7
    Exception=C0000005
    EAX=00000000 EBX=00000000 ECX=023D0310 EDX=006B0063
    ESI=00000000 EDI=00D70676 EBP=00D746A4 ESP=00D6C64C
    CS=0000001B DS=00000023 ES=00000023 SS=00000023
    Flags=00010246

    Stack:
    1 : TakeCmd.dll 0001:00004cd7
    2 : TakeCmd.dll 0001:0000ba86
    3 : TakeCmd.dll 0001:00009671
     
  2. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    TCC 12.00.21 Windows Vista [Version 6.0.6002]
    TCC Build 21 Windows Vista Build 6002 Service Pack 2

    This problem does not manifest for me, but I had to change the F:\ to D:\
    for my system testing.


    On Fri, Aug 13, 2010 at 12:08 PM, Steve Fábián <tc_support@jpsoft.com>wrote:




    --
    Jim Cook
    2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Monday.
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    On Fri, 13 Aug 2010 15:25:32 -0400, Jim Cook <>
    wrote:

    |This problem does not manifest for me, but I had to change the F:\ to D:\
    |for my system testing.

    I can't either. I tried my biggest drive ~46000 files, no
    descriptions
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | On Fri, 13 Aug 2010 15:25:32 -0400, Jim Cook <>
    | wrote:
    |
    || This problem does not manifest for me, but I had to change the F:\
    || to D:\ for my system testing.
    |
    | I can't either. I tried my biggest drive ~46000 files, no
    | descriptions

    In V12 B21 it is inconsistent. I had problems thrice, last two tests
    successful. V9 always works, V10 and V11 always fail. Failure location is
    consistent across versions. Last entry recorded is last file in a directory,
    next entry is from another directory, both subdirectories of the same
    subdirectory of the drive's root.
    --
    Steve
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Not reproducible here (with 625,809 files).

    That GPF address is in the description handling -- check your descript.ion
    file for that directory and see if it's been corrupted.

    Rex Conn
    JP Software
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---Quote---
    || The command below, which works in TCC V9, causes consistent GPFs in
    || V10 and later:
    ||
    || *pdir/s/nej/ou/a:/(a fpn) f:\ > dl.f
    ||
    || F: is a hard drive. File dl.f is created on a different drive
    || (C:\save).
    || When the GPF occurs, the output file is terminated after the second
    || of the lines below (the 150648th line of the file):
    | ---End Quote---
    | Not reproducible here (with 625,809 files).
    |
    | That GPF address is in the description handling -- check your
    | descript.ion file for that directory and see if it's been corrupted.

    I used LIST to view the DESCRIPT.ION files of the parent directory as
    well as both subdirectories (the one actually reported and the one where
    reporting fails). None appear to be corrupted.

    BTW, when description handling is not requested, as in the failing
    command above, why would there be an issue with corrupted description files?
    --
    Steve
     

Share This Page