Why Did a Batchfile Meant to Back Files Up to Startup Folder Copy All System32 Files
I use AutoHotKey a lot and like to have all my scripts running at startup with my changes so I made a batchfile to back up everything from my AutoHotKey folder into the windows startup folder and scheduled it to run daily:
xcopy ".*" "C:Users%USERPROFILE%AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup" /y
I placed this file in my AutoHotKey directory and when it ran it picked up itself since I forgot to use ".*.ahk" to only get the AutoHotKey files. So now I have this batch file also in my startup folder, which is pointless but harmless (so I thought).
After a couple restarts suddenly my computer went haywire at startup, opening a ton of files and starting a bunch of different programs. I got thousands of "you cannot open a .dll" errors.
I thought I had a virus and rebooted in safe mode. I remembered this script and checked my startup folder before re-installing windows and saw thousands of files in there, which I deleted.
As an experiment I restarted my computer a couple times without issue. Then I placed the batch file back in the startup folder and my computer went haywire again.
My question is, why would it copy everything from anything besides the directory it is placed in? Also, why does it only cause this issue on startup? I ran the file in the Startup directory normally and nothing happened.
batch-file cmd startup xcopy
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
|
show 4 more comments
I use AutoHotKey a lot and like to have all my scripts running at startup with my changes so I made a batchfile to back up everything from my AutoHotKey folder into the windows startup folder and scheduled it to run daily:
xcopy ".*" "C:Users%USERPROFILE%AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup" /y
I placed this file in my AutoHotKey directory and when it ran it picked up itself since I forgot to use ".*.ahk" to only get the AutoHotKey files. So now I have this batch file also in my startup folder, which is pointless but harmless (so I thought).
After a couple restarts suddenly my computer went haywire at startup, opening a ton of files and starting a bunch of different programs. I got thousands of "you cannot open a .dll" errors.
I thought I had a virus and rebooted in safe mode. I remembered this script and checked my startup folder before re-installing windows and saw thousands of files in there, which I deleted.
As an experiment I restarted my computer a couple times without issue. Then I placed the batch file back in the startup folder and my computer went haywire again.
My question is, why would it copy everything from anything besides the directory it is placed in? Also, why does it only cause this issue on startup? I ran the file in the Startup directory normally and nothing happened.
batch-file cmd startup xcopy
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.%~dp0
– Squashman
Nov 15 '18 at 19:26
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
1
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
1
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
1
Just to make you aware that, in modern Windows PC's,C:Users%USERPROFILE%AppDataRoamingcan be represented more succinctly by%AppData%.
– Compo
Nov 15 '18 at 20:39
|
show 4 more comments
I use AutoHotKey a lot and like to have all my scripts running at startup with my changes so I made a batchfile to back up everything from my AutoHotKey folder into the windows startup folder and scheduled it to run daily:
xcopy ".*" "C:Users%USERPROFILE%AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup" /y
I placed this file in my AutoHotKey directory and when it ran it picked up itself since I forgot to use ".*.ahk" to only get the AutoHotKey files. So now I have this batch file also in my startup folder, which is pointless but harmless (so I thought).
After a couple restarts suddenly my computer went haywire at startup, opening a ton of files and starting a bunch of different programs. I got thousands of "you cannot open a .dll" errors.
I thought I had a virus and rebooted in safe mode. I remembered this script and checked my startup folder before re-installing windows and saw thousands of files in there, which I deleted.
As an experiment I restarted my computer a couple times without issue. Then I placed the batch file back in the startup folder and my computer went haywire again.
My question is, why would it copy everything from anything besides the directory it is placed in? Also, why does it only cause this issue on startup? I ran the file in the Startup directory normally and nothing happened.
batch-file cmd startup xcopy
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
I use AutoHotKey a lot and like to have all my scripts running at startup with my changes so I made a batchfile to back up everything from my AutoHotKey folder into the windows startup folder and scheduled it to run daily:
xcopy ".*" "C:Users%USERPROFILE%AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup" /y
I placed this file in my AutoHotKey directory and when it ran it picked up itself since I forgot to use ".*.ahk" to only get the AutoHotKey files. So now I have this batch file also in my startup folder, which is pointless but harmless (so I thought).
After a couple restarts suddenly my computer went haywire at startup, opening a ton of files and starting a bunch of different programs. I got thousands of "you cannot open a .dll" errors.
I thought I had a virus and rebooted in safe mode. I remembered this script and checked my startup folder before re-installing windows and saw thousands of files in there, which I deleted.
As an experiment I restarted my computer a couple times without issue. Then I placed the batch file back in the startup folder and my computer went haywire again.
My question is, why would it copy everything from anything besides the directory it is placed in? Also, why does it only cause this issue on startup? I ran the file in the Startup directory normally and nothing happened.
batch-file cmd startup xcopy
batch-file cmd startup xcopy
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
asked Nov 15 '18 at 19:22
azephyrburkeazephyrburke
337
337
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.%~dp0
– Squashman
Nov 15 '18 at 19:26
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
1
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
1
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
1
Just to make you aware that, in modern Windows PC's,C:Users%USERPROFILE%AppDataRoamingcan be represented more succinctly by%AppData%.
– Compo
Nov 15 '18 at 20:39
|
show 4 more comments
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.%~dp0
– Squashman
Nov 15 '18 at 19:26
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
1
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
1
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
1
Just to make you aware that, in modern Windows PC's,C:Users%USERPROFILE%AppDataRoamingcan be represented more succinctly by%AppData%.
– Compo
Nov 15 '18 at 20:39
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.
%~dp0– Squashman
Nov 15 '18 at 19:26
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.
%~dp0– Squashman
Nov 15 '18 at 19:26
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
1
1
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
1
1
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
1
1
Just to make you aware that, in modern Windows PC's,
C:Users%USERPROFILE%AppDataRoaming can be represented more succinctly by %AppData%.– Compo
Nov 15 '18 at 20:39
Just to make you aware that, in modern Windows PC's,
C:Users%USERPROFILE%AppDataRoaming can be represented more succinctly by %AppData%.– Compo
Nov 15 '18 at 20:39
|
show 4 more comments
1 Answer
1
active
oldest
votes
You got all the good advice already in the comments above. But let me give you some more oversight...
add pause to the bottom of your script. Now run the script, by double clicking on it.
You will notice that cmd.exe have started up in its working directory, being C:WindowsSystem32 So by you doing:
xcopy ".*" ...
You are affectively copying from the working directory c:windowssystem32
So instead do:
xcopy "C:pathtofiles*" ....
You could also just cd /d C:pathtofiles but either way, using full path is the best solution, meaning the script can be placed anywhere on disk... or any disk for that matter.
Additionally, as mentioned already in a comment by Compo, there is a preset AppData variable in all modern Windows versions, you can see this by running from cmd.exe:
echo %AppData%
So you should just be be able to run your script as:
xcopy "C:pathtofiles*" "%AppData%MicrosoftWindowsStart MenuProgramsStartup" /y
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53326580%2fwhy-did-a-batchfile-meant-to-back-files-up-to-startup-folder-copy-all-system32-f%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You got all the good advice already in the comments above. But let me give you some more oversight...
add pause to the bottom of your script. Now run the script, by double clicking on it.
You will notice that cmd.exe have started up in its working directory, being C:WindowsSystem32 So by you doing:
xcopy ".*" ...
You are affectively copying from the working directory c:windowssystem32
So instead do:
xcopy "C:pathtofiles*" ....
You could also just cd /d C:pathtofiles but either way, using full path is the best solution, meaning the script can be placed anywhere on disk... or any disk for that matter.
Additionally, as mentioned already in a comment by Compo, there is a preset AppData variable in all modern Windows versions, you can see this by running from cmd.exe:
echo %AppData%
So you should just be be able to run your script as:
xcopy "C:pathtofiles*" "%AppData%MicrosoftWindowsStart MenuProgramsStartup" /y
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
add a comment |
You got all the good advice already in the comments above. But let me give you some more oversight...
add pause to the bottom of your script. Now run the script, by double clicking on it.
You will notice that cmd.exe have started up in its working directory, being C:WindowsSystem32 So by you doing:
xcopy ".*" ...
You are affectively copying from the working directory c:windowssystem32
So instead do:
xcopy "C:pathtofiles*" ....
You could also just cd /d C:pathtofiles but either way, using full path is the best solution, meaning the script can be placed anywhere on disk... or any disk for that matter.
Additionally, as mentioned already in a comment by Compo, there is a preset AppData variable in all modern Windows versions, you can see this by running from cmd.exe:
echo %AppData%
So you should just be be able to run your script as:
xcopy "C:pathtofiles*" "%AppData%MicrosoftWindowsStart MenuProgramsStartup" /y
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
add a comment |
You got all the good advice already in the comments above. But let me give you some more oversight...
add pause to the bottom of your script. Now run the script, by double clicking on it.
You will notice that cmd.exe have started up in its working directory, being C:WindowsSystem32 So by you doing:
xcopy ".*" ...
You are affectively copying from the working directory c:windowssystem32
So instead do:
xcopy "C:pathtofiles*" ....
You could also just cd /d C:pathtofiles but either way, using full path is the best solution, meaning the script can be placed anywhere on disk... or any disk for that matter.
Additionally, as mentioned already in a comment by Compo, there is a preset AppData variable in all modern Windows versions, you can see this by running from cmd.exe:
echo %AppData%
So you should just be be able to run your script as:
xcopy "C:pathtofiles*" "%AppData%MicrosoftWindowsStart MenuProgramsStartup" /y
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
You got all the good advice already in the comments above. But let me give you some more oversight...
add pause to the bottom of your script. Now run the script, by double clicking on it.
You will notice that cmd.exe have started up in its working directory, being C:WindowsSystem32 So by you doing:
xcopy ".*" ...
You are affectively copying from the working directory c:windowssystem32
So instead do:
xcopy "C:pathtofiles*" ....
You could also just cd /d C:pathtofiles but either way, using full path is the best solution, meaning the script can be placed anywhere on disk... or any disk for that matter.
Additionally, as mentioned already in a comment by Compo, there is a preset AppData variable in all modern Windows versions, you can see this by running from cmd.exe:
echo %AppData%
So you should just be be able to run your script as:
xcopy "C:pathtofiles*" "%AppData%MicrosoftWindowsStart MenuProgramsStartup" /y
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
answered Nov 16 '18 at 7:12
Gerhard BarnardGerhard Barnard
8,70531232
8,70531232
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53326580%2fwhy-did-a-batchfile-meant-to-back-files-up-to-startup-folder-copy-all-system32-f%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Why don't you use the a full path for the source instead of a relative path? Would even be better if used the batch files path.
%~dp0– Squashman
Nov 15 '18 at 19:26
That's what I'm switching to, I'm just trying to figure out why it would behave this way in the first place
– azephyrburke
Nov 15 '18 at 19:41
1
Because you are running as admin. You are having problems because you don't follow good practise. Use full paths. Assume nothing.
– CatCat
Nov 15 '18 at 19:42
1
My understanding is that you are spawning a child process at startup and it is inheriting the environment from the parent process. At startup the working directory is SYSTEM32.
– Squashman
Nov 15 '18 at 19:42
1
Just to make you aware that, in modern Windows PC's,
C:Users%USERPROFILE%AppDataRoamingcan be represented more succinctly by%AppData%.– Compo
Nov 15 '18 at 20:39