EEDK cannot see all directories on a system

[andrew_robinson]

Strange one. I have an EEDK CMD script to try and fix WMI issues. When I run a simple "dir %windir%\system32\wbem\*." it does not list the folders called REPOSITORY, MOF or PERFORMANCE. Same even after they are deleted and recreated by service restarts. Same after reboot. Same if I grant full control to everyone to the missing folders. If I run the script locally in a PSEXEC shell as SYSTEM , it works fine. If I run it from taskscheduler as system, it works fine. If I run it remotely from PSEXEC, telling it to use system, it works fine. Very odd.

[cdinet]

The agent should run that as system, unless service account has been modified for what the agent services run under.  Can you have your script generate a detailed log for what it is doing?  Do any of the windows event logs show anything it doesn't like?

[andrew_robinson]

I can write a log - it's just a question of what to put in it. The windows event log auditing is also proving a bit of a challenge to be honest. So, the script could see (just a dir *.) all folders when I copied WBEM to c:\. I renamed that WBEM2 and copied that to windows\system and the script cannot "dir *." any folders in that at all! More tomorrow....looking for a free, easy, file audit tool....

[cdinet]

What about using the /s option for showing sub folders?

/a Show all files

/s Include all subfolders.

/b Bare format (no heading, file sizes or summary)

[andrew_robinson]

None of that works either. I think it has something to do with the CMD process that is running. I have managed to get access protection to log some tests. I created TEST.TXT in each folder and if delete TEST.TXT with the script, it deletes from c:\wbem2 with the following message

NT AUTHORITY\SYSTEM ran C:\Windows\SysWOW64\cmd.exe, which accessed the file C:\wbem2\test.txt, violating the rule "TEST.TXT". Access was allowed because the rule wasn't configured to block.

It does not delete or even report on the same file in c:\windows\system32\wbem or c:\windows\system32\wbem2. I suspect this is something to do with the 32\64 bit nature of CMD.

If I delete the file locally in a cmd window, I get this

Andrew ran C:\Windows\System32\cmd.exe, which accessed the file C:\Windows\System32\wbem\test.txt, violating the rule "TEST.TXT"

If I load C:\Windows\SysWOW64\cmd.exe as my CMD, it does not DIR the test.txt file locally.

Think I am on to something....

[spederse]

This looks like it could be related to this:
The EEDK Sctipt is running as SYSTEM in 32 bit context and Windows try to "help you". See below for the solution. This is a copy from my EEDK code example: GitHub SteenP repository - /SteenPedersen/EEDK_Batch_Template

:: Using sysnative
:: Sysnative is a virtual folder, a special alias, that can be used to access the 64-bit
:: System32 folder from a 32-bit application or script. If you for example specify this
:: folder path in your application's source code:
:: C:\Windows\Sysnative
:: the following folder path is actually used:
:: C:\Windows\System32
:: Using the 'Sysnative' folder will help you access 64-bit tools from 32-bit code
:: Like: %windir%\sysnative\Manage-BDE.exe -status
:: The Manage-BDE.exe only exist in \System32\ folder and not in the SysWOW64

More details Google "sysnative-folder-64-bit-windows"