Today I have made an investigation and I found out that the folder C:\windwos was created during agent upgrade. The self-contained agent installation package created a child process wscfg32.exe which handles the big part of the installation. Then wscfg32.exe created another child process vulscan.exe /changesettingsnoreport (I don’t know really what vulscan is doing when this switch is used) and this is the process which is going to create the folder C:\windwos.
The weird thing that I have discovered when I was testing a scheduled task to delete this folder is that it will be created again by the vulnerability scanner. (once vulscan start with the switch /rebootifneeded)
Am I the only one who is facing this issue
"Yes and no".
So - WSCFG32.EXE is the binary that's ultimately responsible for the agent install. It's the binary you can call directly from LDLOGON on the Core if you want to install an agent by hand (for instance).
We do dump some things into the Windows directory \ its sub-directories (stuff around alerting & things like POWEROFF.EXE which goes into SYSWOW64). I take it that you're not installed to C:\Windows ? I don't have a VM where Windows insn't installed to C:\Windows , but you can have a peek inside the directory yourself if it's causing you panic. I am not convinced it's something to lose sleep over.
Logically speaking "agent install" would be a sensible time for such a thing to occur (
Vulscan itself is our vulnerability scanner -- but it's also responsible for updating agent settings (amongst other things). That's what it's doing with the command-line you've seen above. Common vulscan switches can be found here -- About Vulscan switches for Windows clients (mainly to calm any discomfort, there's not a lot of situations in which you would need to use command line switches unless specifically told to by support or so), as most things are handled through agent behaviour files (the things vulscan was downloading / updating) now.
Any "active use" of command-line switches is primarily for troubleshooting these days.
Does that help you as a starting point?
The question is "what's the actual problem" somewhat remains - are there files in the directory? If it's just the existence of the directory that concerns / offends and it's empty, I see no problem with removing it once the install has completed.