Can't interrupt REGDIR

May 20, 2008
12,167
133
Syracuse, NY, USA
I just want to interrupt it, not make it pause ... you know, like DIR, PDIR, FFIND. It'd be useful especially considering that recursion is the default.

This command took quite a long time. I couldn't interrupt it. It seems to show a couple problems.

Code:
v:\> timer & regdir /v /d hklm | ffind /k /v /m /t"JPSoft" & timer
Timer 1 on: 13:52:05
         PeriodShortcut : REG_DWORD : 1
Timer 1 off: 13:58:52  Elapsed: 0:06:47.086

1. It didn't do what I asked it to do!

2. the time!!! ... the TCC running REGDIR showed 0 CPU for most of those 6+ minutes. In sharp contrast, my (ancient) REGFIND.EXE can go through HKLM, looking for "PeriodShortcut" (finding 536 of them) in about 11 seconds.

I'll experiment more.
 

rconn

Administrator
Staff member
May 14, 2008
12,556
167
1. It didn't do what I asked it to do!

Works fine here; returns only the keys / values with "Jpsoft" in them (several hundred of them).

2. the time!!! ... the TCC running REGDIR showed 0 CPU for most of those 6+ minutes. In sharp contrast, my (ancient) REGFIND.EXE can go through HKLM, looking for "PeriodShortcut" (finding 536 of them) in about 11 seconds.

I don't know why you would be trying that syntax - it's about the most inefficient way to search the registry imaginable. Most of the time is consumed by REGDIR formatting & outputing binary data that you don't even care about.
 
May 20, 2008
12,167
133
Syracuse, NY, USA
I have only 19 "jpsoft"s in HKLM (confirmed with REGEDIT). They're all found when I look in hklm\software\microsoft\windows. One instance of the wrong string is found when I look in hklm\software\microsoft (an enclosing key!). When I use GREP.EXE instead of FFIND, the correct strings are found in both cases.

1575234810176.png


You're probably right about the binary data. There are many REG_BINARY values (notably in HKLM\HARDWARE) with tens (maybe hundreds) of thousands of bytes of data.

What is a better way to search the registry for strings (in keys, values, and data) with TCC?
 
May 20, 2008
12,167
133
Syracuse, NY, USA
PERHAPS an acceptable workaround?

Use paging with one second: /P1 ...
Huh? You still get a 1-second per page delay. At that rate it would days to output all of HKLM.

One odd thing ... if I do

Code:
regdir /p1 /v /d hklm | grep .

I don't get any delays and Ctrl-C stops both regdir and grep (and Esc does nothing). Whereas if I do

Code:
regdir /v /d hklm | grep .

Ctrl-C stops grep and leaves regdir running.
 
May 20, 2008
12,167
133
Syracuse, NY, USA
You're probably right about the binary data. There are many REG_BINARY values (notably in HKLM\HARDWARE) with tens (maybe hundreds) of thousands of bytes of data.
Yup! The output of

Code:
regdir /v /d HKEY_LOCAL_MACHINE\HARDWARE\ACPI\DSDT\DELL__\CBX3___\01072009

has 862,000 characters. I reckon that accounts for over 280,000 bytes of data (all in one value).

And though I don't know what FINDSTR's limit is, when I pipe the output of "regdir /v /d hklm" to FINDSTR, I get "Line too long" 354 times
 
May 20, 2008
12,167
133
Syracuse, NY, USA
I did both REGDIRs ("microsoft" subkey and "microsoft\windows" subkey) sending the output to files instead of piping it to FFIND.

FFIND found the correct text in both files when NOT in a pipe (first two below) and failed (as described earlier) when in a pipe (second two below).

Code:
v:\> ffind /k /v /m /t"com.jpsoft" microsoft.key
          C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
                3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
                A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\

v:\> ffind /k /v /m /t"com.jpsoft" windows.key
        C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
              3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
              A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\

v:\> type microsoft.key | ffind /kmvt"com.jpsoft"
9:45

v:\> type windows.key | ffind /kmvt"com.jpsoft"
        C:\ProgramData\regid.2002-09.com.jpsoft\ : REG_SZ : 1
              3F819E44FE0B92C488AD58A07AD68F7C : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\
              A3ED2CFA97F2A264BB531D4A16FE9CAC : REG_SZ : C:\ProgramData\regid.2002-09.com.jpsoft\

In a pipe, GREP gets it right in both cases. So does FINDSTR (with several "line too long" errors).
 
May 20, 2008
12,167
133
Syracuse, NY, USA
In a pipe, FFIND seems to fail beyond some point.

"D4373260-1185-49AC-993B-A31209FBD6CC" appears near the end of "DIR /s c:\" (~64MB output). And I see this (first line of output is fishy):

Code:
v:\> dir /s c:\ | ffind /vkmt"D4373260-1185-49AC-993B-A31209FBD6CC"
latedpackages-package~31bf3856ad364e35~amd64~pt-pt~10.0.18362.476.mum
 Directory of  C:\Windows\{D4373260-1185-49AC-993B-A31209FBD6CC}\*
    Total for:  C:\Windows\{D4373260-1185-49AC-993B-A31209FBD6CC}\
 
May 20, 2008
12,167
133
Syracuse, NY, USA
I created a big (88,888,897 bytes) file like this ... while I was having dinner ... it took a while.

Code:
(do i=1 to 10000000 ( echo %i )) > reallybigfile.txt

FFIND worked well (and quite fast) when not in a pipe. This is correct and took less than 4 seconds.

Code:
v:\> ffind /mkvt"123456" reallybigfile.txt
123456
1123456
1234560
1234561
1234562
1234563
1234564
1234565
1234566
1234567
1234568
1234569
2123456
3123456
4123456
5123456
6123456
7123456
8123456
9123456

... not so when in a pipe. This is wrong and took 44 seconds.

Code:
v:\> type reallybigfile.txt | ffind /mkvt"123456"
123456
1557
3123456
987591
6123456
987591
9123456