Recently when searching in File Explorer or the W10 search bar, I get the message search indexing was turned off. I have tried several things to fix this, however I am unable to turn on the service.
Things that could potentially be relevant:
I recently migrated my C: drive to a new NVME SSD using Macrium Reflect.
After migrating I gave my account ownership (using File Explorer) of all directories on the new C: drive since I will be the only one using the computer and want to give programs write permissions in certain folders they would otherwise be unable to access.
The first solution I tried was to Rebuild the Windows Search Index, however nothing occurs upon selecting that option. I looked in the Registry Editor to ensure that the SetupCompleteSuccessfully registry had a value of 0. Finally, I checked the Windows Search service from within the Services program. It is listed as Automatic (Delayed Start) and isn't running. When I attempt to run the service I get the following message:
I then checked the Event Viewer, where under Windows Logs>System I see the following error:
I also tried merging a new Windows Search .reg file, but nothing changed.
Related
So basically I customized a Windows 10 install. I have the PerfLogs, Program Data, Temp and Users folders in C:\ replaced as symlinks to their actual location to D:\
The purpose being, I will only keep a image backup of C:\ and when the need arises that I need a fresh install of the OS, I will only overwrite the whole C: drive with the backup and don't even have to touch my old user profiles. It works without a glitch even as I moved my C: to an SSD.
I did it with a few simple tricks (I don't exactly remember everything I did, but once I got the build right, I just left it as it is as I thought I would never have to touch it again):
I remembered following tips and other guides like this:
https://commaster.net/content/windows-installation-tips-moving-user-folder-another-drive
the difference being I used symlinks instead of junctions with mklink command.
Some modification with registry and other files.
Several stages of booting until everything has been transferred and having windows re-create the profiles and configurations.
Anyways, I had to fix my Mom's PC, which was in a state of disarray as she thought she had to save all her files in C:\ and NEVER in Documents. I opted to install my customized Windows install, so if I need to fix it again, it would just be a cinch.
Before building this custom Windows install, I've made backups of my system with my usual backup tool, Paragon Partition Manager. They worked fine and when I had to change PC builds, such as changing my motherboard, all I had to do was change the drivers. So I thought with my custom Windows 10 install, that's all I had to do for my Mom's PC.
But I kept running into problems with Window's User Profile Service.
At first, it was having difficulty loading the Administrator account and seems to be defaulting to C:\Windows\System32\config\systemprofile, as it cannot seem to write to it's D:\Users\Administrator folder. I quickly fixed that, but, still, it can't load the Start Menu and other services.
The only one that was working almost completely was the user (just one - me) that was existing when I created the backup AND only works with a copy of the corresponding folder in D:\Users\MyUsername.
Obviously I wanted to create a user just for my Mom and one that is completely working and I don't wanna leave a copy of D:\Users\MyUsername in her PC. I figured all I had to do was create a user profile in Control Panel and Windows will recreate everything and all the configurations. The add user service in Control Panel wasn't working with Administrator, but only with MyUsername. But whenever I try to sign in to the newly created user, the "User Profile Service failed to sign-in" keeps popping up. I can sign into it in safe mode, at the first seemingly recreating everything with the first-time-sign-in-welcome-screen, but a lot of the services are not working. So creating another user profile with this new profile doesn't work.
More notably, I've tried:
net user username /add
and adding through advanced user profiles:
control userpasswords2
But the new registry keys for the new users in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList never gets created -- even after I go safe mode and manage to sign in to the new users.
I've also considered it might be a user permission issue, somehow being carried over from my PC build (if that makes sense, it still doesn't to me). Anyways, so with the newly created user logged in with safe mode, I tried changing permission for C: and D: for every single group to "Full Control". Then from that newly created user, create another user either through net user username /add or control userpasswords2. I even tried booting to Linux LiveCD and chmod-ding everything to 777 (I'm not even sure how that transfer to an NTFS. Then I try to sign in and even if I can forcibly sign in, it just isn't a glitch-free user profile.
Not really sure of my exact question, but here is the situation:
I have an application (WinForms, C# .Net) that I am developing in Visual Studio 2012. It does a lot of things but the important bit is that it needs to read files from a certain location.
In this case, the location of the files is on a server and my machine has a mapped network drive setup for accessing the files. I can manually navigate to the files with Windows Explorer fine.
I have the following line in my code which is highlighting the issue:
System.IO.File.Exists("X:\\A Folder\\a_file.txt");
And that file does exist in that location. However this is where the problem occurs: if I build the solution and run the .exe directly from the "bin" folder (double-click). The code is fine, and it finds the file. But if I run it with visual studio then I get a "file not found" exception.
I am putting this down to the fact that Visual Studio is running in "Administrator" mode (I forget why I needed this, but I do). Now this makes sense if you consider that the "administrator" account does not have the "X:\" drive mapped. However, this has never been a problem until I upgraded to Windows 10 last week.
So my question is:
Does Visual Studio Administrator mode work differently in Windows 10? In this case, does it handle mapped network drives differently?
It's worth noting I upgraded from Windows 7, so I cannot confirm if this issue is also present in 8 and 8.1 or not.
And before anyone asks, let's just say it has to be a mapped drive. No UNC paths allowed!
So I have found a solution/workaround. Kind of seems like a wasted bounty now, so if someone has other suggestions that are better then please post and I will review them and award as applicable. Or even if somebody can make a more detailed version of my solution then I will award that one.
The issue is probably not specific to Visual Studio, but would occur with any application running with elevated privileges. Anyway, the solution I found is to add a registry key that enables the same shared drives to be accessible when running in administrator mode.
The registry key location is:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System
And the key to add is called:
EnableLinkedConnections
And should be created as a DWORD with a value of 1 (0x00000001)
I checked with the machines running Windows 7 and they do NOT have this key, yet they still work fine. So I expect this isn't the only solution, but it does seem to work (no side effects noted yet). I would assume that Windows 10 has a specific setting somewhere that by default prevents mapped drives from automatically being available with "run as administrator".
For reference, I found this information here.
In fact, here is a more "official" recommendation for using this reg key.
This is unlikely to have anything to do with Windows 10, just with the configuration of your machine. What you describe is normal and covered by this KB article. Nothing I can check for myself so just try the recommended workarounds, follow up at superuser.com if necessary.
Different users/system tasks maybe running. As such, you have the X drive mapped, but others do not. You could do the drive mapping on additional users on your Windows installation as well. As you stated, this should not be a Windows 10 only issue, but also Windows 7+ and elevated privileges.
Maybe you could use a configured parameter for the X: path and load at runtime, or even try using UNC paths which will resolve at runtime and not need the drive to be mapped.
\\ServerNameOrIP\A Folder\a_file.txt.
In the code, you would need:
System.IO.File.Exists("\\\\ServerName\\A Folder\\a_file.txt");
I have a very old application which I've moved from computer to computer over the years. I was probably running NT or maybe even Windows 95 when I got it. It still runs fine, but I recently tried to back up some of the files I created using it and I find that they are hidden. When I run the app I can read them or write them, but when I try to access them either via the command line or Windows Explorer they are not found. I can see them from the cygwin command line, but I would really prefer explorer.
My theory is that this is because my app is so old that it is putting user data in c:\ProgramFiles(x86)\MyApp\data rather than in some User\AppData directory which is what more recent versions of Windows are happier with.
What I've tried:
Using attrib to remove hidden attributes (failed with permission issue)
Same, but running attrib in cmd window with admin privileges (no permission error message, but the files do not subsequently show up)
Copying using cygwin command line (got unhelpful message "omitting directory `data'")
Any suggestions what I could try next? I am running Windows 7.
I would happy with a fix that I could do once and would fix it for good (setting permissions somehow?); I would be satisfied with a workaround like "run the following command every time you want to back files up").
Edit: I noticed something strange which may be a clue for someone more knowledgeable than I am: for files which have been modified recently, as opposed to created, doing a dir shows the file information for the old version, even though cygwin shows the new information and that's what I see when I read the file using the app.
Let's say I have
c:\prod\foo.txt
and
c:\work\foo.txt
I would like to get c:\prod\foo.txt automatically and immediately updated from the other file, whenever I change & save c:\work\foo.txt
How can this be accomplished? Installing tools is okay. Windows 7 and up.
Symbolic linking is not a solution for me, as the c:\work is deleted every now and then.
Have you looked at SyncToy?
A: Run SyncToy silently addresses this issue.
SyncToy can be used in conjunction with the Windows Scheduler to automate sync operations.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.