Can't find the physical file for LocalSystem User.Config (at least not where it's supposed to be)

2013-11-21

Question

_{Thursday, November 21, 2013 4:01 PM}

I have written a service using Visual Studio's 2012 VB.Net that is installed on a Windows 2008 R2 server (SP1) and runs under the LocalSystem account. In addition to a number of application settings, the service also uses a single user setting to track a string representation of the last run date.

Because this is VB.Net, setting the user setting is pretty straight forward:

My.Settings.LastRunDate = Today.ToString("yyyy/MM/dd")
My.Settings.Save()

User settings are saved to the profile's user.config file. For LocalSystem, this *should* be buried under a number of subfolders beginning at C:\Windows\System32\config\systemprofile\AppData\Local. However, upon examination, there are only 2 folders under Local: Microsoft and another for a third-party application - there is no folder for my company name (and no way to get to the config file).

I want to stress that the service is running perfectly fine. The setting is getting updated correctly and when retrieved is returning the correct value. This value is persisting across service restarts and even server restarts. If we rebuild the service, it correctly resets to the default value. I just want to know what has happened to the file.

I modified the service to query the Configuration Manager and return the path of the user.config file:

Configuration.ConfigurationManager.OpenExeConfiguration(Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath

The path returned makes perfect sense and follows the expected pattern. But if I plug this path into the Run command or in a command prompt, I get a message that it can't be found.

I took this a step further and passed the path to the constructor of the System.IO.FileInfo object and queried the "Exists" method - it came back true (the file is indeed where it says it is).

At this point, my brain was beginning to hurt, so it took the next obvious step and invoked the FileInfo's CopyTo method to copy the settings file to the root of the C directory. Sure enough, a file was created and it is exactly what a user.config file should look like - except that I can't find the original.

I've tried to find this thing through Windows Explorer and from the Command Prompt using every imaginable attribute I can think of, but without any success. I seem to have found Schrodinger's file - it both exists and doesn't exist at the same time (sorry, my attempt at weak humor).

Granted, the program works as intended, but I have two issues with not being able to access the physical file:

1) It complicates testing - the only way we can reset the value to its default is to rebuild the application under a new version number.

2) It will make future troubleshooting difficult - one might want to check the current setting value to confirm that it is updating correctly.

I'm hoping someone can shed some light on this behavior. I've read Raghaendra Prabhu's Client Settings FAQ but it doesn't seem to address my problem. I've been able to use user settings in typical desktop applications and have never encountered this sort of issue before.

Kevin

All replies (8)

_{Monday, November 25, 2013 9:41 PM ✅Answered}

Thanks for trying, I guess I wasn't clear enough when I mentioned that I had checked for hidden and system attributes. As it turns out, the problem has resolved itself - sort of...

We did a couple of additional rebuilds this morning as we had to tweak some internal workings for some further testing. Low and behold, the user setting directory has now appeared under Local (as it should). What is interesting is that there are only two version directories that exist for this application, the version number and timestamp for each corresponding to the two separate builds today - but there is no evidence of the previous versions from last week. The tweaks had nothing to do with user settings (just adjusting some internal counters).

I'm going to follow this up with our own internal Server Ops group and see if they can shed some light on this behavior. I suspect there's likely some process they're running that might have some impact on this.

Kevin

_{Thursday, November 21, 2013 4:33 PM}

I don't have a service running using a local system account or a Windows 2008 R2 server but for my user the files for various applications settings are saved in the top image belows directory. And I just picked one although I realize what app it is for even though the app has a different name than the folder that settings file is located in. Perhaps before I saved the app it created that file using the default app name of WindowsApplication1.

The path is -

C:\Users\John\AppData\Local\WindowsApplication1\WindowsApplication1.vshos_Url_4xl3rnns0tttt20wtn0wxhdqebgybgyk\1.0.0.0

Please BEWARE that I have NO EXPERIENCE and NO EXPERTISE and probably onset of DEMENTIA which may affect my answers! Also, I've been told by an expert, that when you post an image it clutters up the thread and mysteriously, over time, the link to the image will somehow become "unstable" or something to that effect. :) I can only surmise that is due to Global Warming of the threads.

_{Friday, November 22, 2013 6:01 PM}

Yes, the user.config files for your typical user accounts is pretty straightforward, but the rules are a little bit different for the LocalSystem account (actually, the difference is really just where its profile gets stored).

Just to elaborate, I know precisely where the user.config file for my service is stored. The configuration manager reports its location as:

C:\Windows\system32\config\systemprofile\AppData\Local\Altalink_LP\DobleLoad.exe_Url_wnasa0k4uz14rocyovkolno2r1zkhujb\1.0.5072.20423\user.config

System.IO.FileInfo will confirm this location as valid and that the file exists.

*EXCEPT* I can't navigate to that location. I can only get as far as "Local" - nothing exists beyond that point. So I've got the system telling me it's there - and another part of the system telling me it isn't. Just to rule out the obvious, I'm local administrator on the server, I've checked for hidden/system folders, the server has been rebooted, I run the command prompt as administrator and try to navigate that way... - nothing works. Even if this is the localsystem account, I can't see why gaining physical access to the file is so difficult.

The next step will be to move this to another server and see if the problem repeats itself.

Kevin

_{Monday, November 25, 2013 5:51 AM}

The next step will be to move this to another server and see if the problem repeats itself.

What's the result now?

Nice day. : )

remember make the reply as answer and vote the reply as helpful if it helps.

_{Monday, November 25, 2013 3:37 PM}

Yes, the user.config files for your typical user accounts is pretty straightforward, but the rules are a little bit different for the LocalSystem account (actually, the difference is really just where its profile gets stored).

Just to elaborate, I know precisely where the user.config file for my service is stored. The configuration manager reports its location as:

C:\Windows\system32\config\systemprofile\AppData\Local\Altalink_LP\DobleLoad.exe_Url_wnasa0k4uz14rocyovkolno2r1zkhujb\1.0.5072.20423\user.config

System.IO.FileInfo will confirm this location as valid and that the file exists.

*EXCEPT* I can't navigate to that location. I can only get as far as "Local" - nothing exists beyond that point. So I've got the system telling me it's there - and another part of the system telling me it isn't. Just to rule out the obvious, I'm local administrator on the server, I've checked for hidden/system folders, the server has been rebooted, I run the command prompt as administrator and try to navigate that way... - nothing works. Even if this is the localsystem account, I can't see why gaining physical access to the file is so difficult.

The next step will be to move this to another server and see if the problem repeats itself.

Kevin

You say nothing exists beyond that point. But how do you know that? The control panel can be used to set folder options to "show hidden files, folders and drives" but that does not show all folders or files on the system.

Perhaps on Windows 2008 R2 "Altalink_L2" is considered a protected operating system file or folder. Therefore without unchecking "Hide protected operating system files (Recommended)" in Folder Options, View then explorer and the command prompt command Dir can not see any folder past "Local" either although programs can still access those folders contents. And they can be pathed to using the Command Prompt if you know the path name. You can even paste the path in explorers path box if you know the path name and it will go there but anything there would be invisible. And explorer would say the path is empty even though it isn't.

_{Monday, November 25, 2013 3:40 PM}

Here's code that creates a "super hidden" folder.

Option Strict On

Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        Me.CenterToScreen()
        Me.Text = "Make a Folder super hidden"
        RichTextBox1.Text = "Text to write to file in super hidden folder"
    End Sub

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim FBD As New FolderBrowserDialog
        If FBD.ShowDialog = Windows.Forms.DialogResult.OK Then
            Dim Path As String = FBD.SelectedPath
            Dim CmdID As Integer = Process.Start("cmd").Id
            System.Threading.Thread.Sleep(1000)
            SendKeys.Send("attrib {+}s {+}h " & """" & Path & """" & "{Enter}")
            System.Threading.Thread.Sleep(500)
            Dim KillCmd As Process = Process.GetProcessById(CmdID)
            KillCmd.Kill()
        End If
    End Sub

    Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
        My.Computer.FileSystem.WriteAllText("C:\Users\John\Desktop\Testing\Secret Hidden Folder\Testing.Txt", RichTextBox1.Text, False)
    End Sub

    Private Sub Button3_Click(sender As Object, e As EventArgs) Handles Button3.Click
        RichTextBox2.Text = My.Computer.FileSystem.ReadAllText("C:\Users\John\Desktop\Testing\Secret Hidden Folder\Testing.Txt")
    End Sub

End Class

_{Tuesday, November 26, 2013 6:47 AM}

Thanks for trying, I guess I wasn't clear enough when I mentioned that I had checked for hidden and system attributes. As it turns out, the problem has resolved itself - sort of...

We did a couple of additional rebuilds this morning as we had to tweak some internal workings for some further testing. Low and behold, the user setting directory has now appeared under Local (as it should). What is interesting is that there are only two version directories that exist for this application, the version number and timestamp for each corresponding to the two separate builds today - but there is no evidence of the previous versions from last week. The tweaks had nothing to do with user settings (just adjusting some internal counters).

I'm going to follow this up with our own internal Server Ops group and see if they can shed some light on this behavior. I suspect there's likely some process they're running that might have some impact on this.

Kevin

I find it extremely unlikely that a process can hide something the windows OS is in charge of like files, folders and things such that setting explorer to show hidden files, folders and protected operating system files would not show those. Nor a process that would mysteriously move those around as how would the configuration manager accept a path that doesn't exist as it apparently can't be found with explorer with appropriate view settings for folder options set?

_{Monday, November 6, 2017 6:55 PM | 1 vote}

I just found this thread and so far it's the only post that I can find that describes the exact problem i'm currently having. I have a simple test console program that prints out the local user config file path using the same method you described. it returns:

C:\Users\myUser\AppData\Local\ConsoleApplication2\ConsoleApplication2.exe_Url_vq4gfueah4jakawmfdwupzi23ohuf1jd\1.0.0.0\user.config

but ConsoleApplication2 is not recognized as a valid subfolder. when I try to get there with either by browsing the Local folder or copying in the complete link it says there is no such path. All other hidden files and folders are displaying correctly as expected.

Wondering if you ever ran into this problem again or figured out the exact cause/solution in the first place. It's driving me absolutely nuts

EDIT: should clarify this is on a Windows 10 system. Program was created in Visual Studio 2015 and installed using a visual studio installer program, all on the same machine, if that matters.

שתף באמצעות

Can't find the physical file for LocalSystem User.Config (at least not where it's supposed to be)

Question

All replies (8)

משאבים נוספים