Welcome!

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

SignUp Now!

Can't interrupt REGDIR

vefatica

vefatica

May
13,160
180
Is there a way to interrupt REGDIR? Ctrl-C/Ctrl-Break don't work.
 
rconn said:
/P
Click to expand...
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.
 
vefatica said:
1. It didn't do what I asked it to do!
Click to expand...

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.
Click to expand...

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.
 
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?
 
Alpengreis said:
PERHAPS an acceptable workaround?

Use paging with one second: /P1 ...
Click to expand...
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.
 
vefatica said:
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.
Click to expand...
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
 
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).
 
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}\
 
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
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate