Welcome!

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

SignUp Now!

FFIND /S and System32? (and an OT mystery)

May
12,846
164
This is correct.
Code:
v:\> ffind /t"Unknown" /v C:\Windows\System32\*.log

---- C:\Windows\System32\w32tm.log
2018-03-13 Tue 03:18:04 Unknown receive error
2018-04-12 Thu 22:59:48 Unknown receive error
2018-04-13 Fri 12:52:27 Unknown receive error

  3 lines in      1 file

Below, FFIND does not process that file.
Code:
v:\> ffind /t"nknown" /s c:\*.log

---- C:\Windows\debug\WIA\wiatrace.log
WIA: 1036.2272 110 0 0 [wiaservc.dll] ERROR: CEventNotifier::AddEventGUID, Trying to register applicatio
n for a unknown global event

---- C:\Windows\inf\setupapi.app.log
>>>  [Build Driver List - unknown device]

---- C:\Windows\inf\setupapi.dev.log
     dvi:      No class installer for 'Unknown driver software package'

  3 lines in      3 files

What's up with that?

And ... off-topic, but a real mystery to me ...

None of my (UNIX) text utils work with the file C:\Windows\System32\w32tm.log. They all seem to be seeing a different file. All TCC commands see the correct file. For example, if TCC opens the file, I get a correct result; when WC.EXE opens the file I get an incorrect result.
Code:
v:\> type s:\w32tm.log | g:\gnu\wc
    113    1114    8598

v:\> g:\gnu\wc s:\w32tm.log
    169    1608   12197 s:\w32tm.log

I manually removed all entries earlier than 2018 from that file, and have restarted the computer a few times since. Below, TCC gets it right and GREP gets it wrong.
Code:
v:\> ffind /t"nknown" /v /k /m C:\Windows\System32\w32tm.log
2018-03-13 Tue 03:18:04 Unknown receive error
2018-04-12 Thu 22:59:48 Unknown receive error
2018-04-13 Fri 12:52:27 Unknown receive error

v:\> g:\gnu\grep nknown C:\Windows\System32\w32tm.log
2012-03-11 Sun 03:17:03 Unknown receive error
2012-03-23 Fri 11:19:09 Unknown receive error
2012-04-12 Thu 03:17:04 Unknown receive error
2012-04-13 Fri 03:17:04 Unknown receive error
2012-04-14 Sat 03:17:04 Unknown receive error
2012-04-15 Sun 03:17:04 Unknown receive error
2012-04-16 Mon 03:17:04 Unknown receive error
2012-06-15 Fri 03:17:04 Unknown receive error
2012-06-16 Sat 03:17:04 Unknown receive error
2012-06-17 Sun 03:17:04 Unknown receive error
2012-06-18 Mon 03:17:04 Unknown receive error
2012-06-19 Tue 03:17:04 Unknown receive error
2012-06-20 Wed 03:17:04 Unknown receive error

If the text utils (GREP, WC) are elevated, they get it right. Is Windows 7 keeping another (older) copy of that file someshere (I can't find it) and doing some sort of file system redirection?
 
I solved that OT mystery by deleting "C:\Users\vefatica\AppData\Local\VirtualStore\Windows\System32\w32tm.log". But that leaves a couple questions.

1. How did it get there in the first place (I've been monkeying with C:\Windows\System32\w32tm.log for years and never ran into this before).
2. How is it that TCC doesn't get redirected to that file, and my text utils do get redirected to that file?
 
32-bit utilities running on X64 Windows?
Nope. I'm on Win7/32. The feature is called "VirtualStore". The entry I deleted was the only one in there after years of using this computer. The feature can be turned off with SECPOL.MSC. I suppose the file was created there because I tried to edit the one in System32 unelevated, but I'm really surprised that that hasn't happened many times in the past.
 
P.S., I discovered it with ProcessMonitor. "Grep "nknown" c:\windows\system32\w32tm.log" led to

1523644084670.png
 
I don't get it! I tried, unelevated, to edit c:\windows\system32\w32tm.log. When I tried to save it, I got an "access denied" message. I did not get a copy in the VirtualStore. Then I edited that file elevated. I could save it. And I still didn't get a copy in the VirtualStore. So I'm still wondering how it got there in the first place.
 
I don't know what "w32tm.log" is (and it isn't on my system).
It's a log file for a time synchronization service which I wrote. Here's the same experiment with a different file (one you might have). The first command below finds it; the second doesn't.

Code:
v:\> ffind /t"DISMLogger" c:\Windows\System32\*.log

---- C:\Windows\System32\InstallPackage_ETW.Log
2010-11-20 13:18:30, Info                  DISM   DISM Provider Store: PID=2188 Getting Provider DISMLogger - CDISMProviderStore::GetProvider

  1 line in      1 file

v:\> ffind /t"DISMLogger" /s c:\*.log

  0 lines in      0 files

Here's another.

Code:
v:\> ffind /t"1.7.0_65-b20" c:\Windows\System32\*.log

---- C:\Windows\System32\jupdate-1.7.0_65-b20.log
INFO: Java Update (1.7.0_65-b20) has been installed successfully on this machine.

  1 line in      1 file

v:\> ffind /t"1.7.0_65-b20" /s c:\*.log

  0 lines in      0 files
 
@vince -

v:\> ffind /a: /t"1.7.0_65-b20" /s c:\*.log

Does that work better?
No.
Code:
v:\> ffind /t"1.7.0_65-b20" c:\Windows\System32\*.log

---- C:\Windows\System32\jupdate-1.7.0_65-b20.log
INFO: Java Update (1.7.0_65-b20) has been installed successfully on this machine.

  1 line in      1 file

v:\> ffind /a: /t"1.7.0_65-b20" /s c:\*.log

  0 lines in      0 files
 
If you try to do a FFIND in one of the system directories (i.e., anything under c:\windows), Windows will sooner or later throw an error (usually access denied), and FFIND will abort.
I don't understand. It works when I specify c:\windows\system32, but not when I specify c:\ with /s. Are you saying system32 itself is OK, but in the second case, it's quitting (without telling me about any error) and never reaching system32?
 
I don't understand. It works when I specify c:\windows\system32, but not when I specify c:\ with /s. Are you saying system32 itself is OK, but in the second case, it's quitting (without telling me about any error) and never reaching system32?

I'm saying that it's failing when going through the c:\windows subdirectories, before it gets to c:\windows\system32. (Most likely in c:\windows\logs.)
 
I'm saying that it's failing when going through the c:\windows subdirectories, before it gets to c:\windows\system32. (Most likely in c:\windows\logs.)
That seems about right. Yes, it quits in c:\windows\logs. But that isn't very user-friendly.

It gives no error message and aborts, not giving me any indication that it hasn't processed 90+% of my request. And I have no way to tell it to continue on such an error.

This all started with my trying to find a second "w32tm.log" file because different apps were seeing different versions of that file. FFIND seemed the perfect tool. Man, was I wrong! The virtualized copy of it was under c:\users; I didn't even come close.

Even without having to read the files, this command
Code:
ffind /s c:\*.pdb
silently quits before finding the ones in "C:\Users\vefatica\AppData\Local\VirtualStore\Program Files\Debugging Tools for Windows (x86)\downstreamstore\"
 
1. Turn off virtual idiocy in Vista+:

Code:
reg ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /f /v "EnableVirtualization" /t REG_DWORD /d 0

2. Purge the "%LocalAppData%/VirtualStore" to never hear of this problem again.
 

Similar threads

Back
Top