0

I ran a .bat file as an administrator. The .bat file said to copy all .dll files from the current directory to the syswow64 directory. Something like:

copy *.dll c:\windows\syswow64

Unfortunately, running it as an administrator set the current directory to c:\windows\system32 rather than the directory that the .bat file was in, so it caused .dll files in system32 to be copied to syswow64. The output showed lots of .dll filenames, but also a lot of Access Denied.s. I terminated the batch as soon as I noticed it was copying something other than the 7 files I had intended to copy.

Is this harmless for that station, or is it problematic? Is there a way to restore the syswow64 folder, or should I not bother? Is there even a way to tell if any .dll files have been affected?

Improve this question
5
  • 4
    That sounds like a horrible idea.
    – Journeyman Geek ♦
    Jun 27, 2015 at 1:14
  • 1
    You might look into using the %~dp0 variable in your batch file to obtain the drive and path that the batch file was started from, rather than assume the current path at start up is the path of the batch file.
    – BeowulfNode42
    Jun 27, 2015 at 1:20
  • @BeowulfNode42, Agreed. If you're doing something this questionable you should consider hard coding the directory rather than letting it "assume the current path." %~dp0 will give you the current drive and path. %~d0 will give you just the current drive, you can add \specific\path to that. You can also use %CD% and you will get the current directory, similar to %~dp0 except %CD% can be used in batch files or directly in the CMD prompt whereas %~dp0 variables are a .bat feature.
    – user431052
    Jun 27, 2015 at 1:38
  • @BiTinerary %0 is the full drive, path, filename and extension of the batch file currently running. %~dp0 is just he drive and path to the batch file currently running. It has nothing to do with the current path. try a batch file on your desktop with the lines cd /d c:\windows then on the next line echo %~dp0
    – BeowulfNode42
    Jun 27, 2015 at 1:47
  • I never mentioned "%0" though.... I know what each of those envars do seeing as how I've used them dozens of times... am I missing/misunderstanding something? My descriptive phrasing may be off, for sure. However I was trying more to describe the application of the envars rather than the nuances.
    – user431052
    Jun 27, 2015 at 2:50

2 Answers 2

Reset to default
4

There might be serious problems in the near future.

Confusingly enough, SysWOW64 holds 32-bit DLLs for use by 32-bit applications that you run, while the System32 folder has 64-bit binaries.

DLL files that are in use or already exist were not replaced, but there are probably a bunch of 64-bit DLLs that are in a folder where only 32-bit binaries are supposed to be loaded (very bad).

Rebooting could have consequences. You should perform sfc /scannow as soon as possible to minimize any loss of system integrity.

Improve this answer
4
  • unless the /y switch was used to "Suppresses prompting to confirm you want to overwrite an existing destination file." then there will just be extra files in the SysWoW64 folder.
    – BeowulfNode42
    Jun 27, 2015 at 1:19
  • Oh that's right, I forgot to factor that in. Thanks.
    – oldmud0
    Jun 27, 2015 at 1:20
  • I guess I'll accept this answer; I wonder though what you're specific reasoning for "very bad" is? It's probably not good, but why is it bad?
    – Dave Cousineau
    Jul 5, 2015 at 23:56
  • @Sahuagin It can confuse programs that depend on DLL detection and lead to random anomalous behavior in the future (caused by program specific behavior).
    – oldmud0
    Jul 6, 2015 at 0:05
1

If they weren't named after system files it will be ok as noting will try to use them. If they were named after system files, as is likely, they will all Access Deny as noone has access to overwrite system files including administrators.

C:\Users\User>icacls c:\windows\system32\notepad.exe
c:\windows\system32\notepad.exe NT SERVICE\TrustedInstaller:(F)
                                BUILTIN\Administrators:(RX)
                                NT AUTHORITY\SYSTEM:(RX)
                                BUILTIN\Users:(RX)

Successfully processed 1 files; Failed processing 0 files

As you can see only TrustedInstaller (the setup/windows update security pseudo user) has permissions to overwrite.

An admin must take ownership, give themselves permission, before being able to overwrite.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .