Results 1 to 15 of 15

Thread: Why is Desktop.ini being displayed when logging on to a user?

  1. #1
    Junior Member
    Join Date
    Nov 2005
    Posts
    21

    Question Why is Desktop.ini being displayed when logging on to a user?

    I've just had to re-instal Windows XP Home, and now find that when logging on to each of the users other than the first user (where I did most of the set up), the Desktop.ini file gets displayed in Notepad, showing

    [.ShellClassInfo]
    LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21787

    Can anyone please let me know why this has suddenly started happening, whether it is a serious problem, and how I can turn it off.

    I've checked the Folder Options, and the users concerned have the setting 'Do not show hidden files and folders'. In fact, the one user where this problem does not occur has the setting 'Show hidden files and folders'.

    All of the users were initially Administrator type, but changing them to Limited makes no difference.

  2. #2
    Triple Platinum Member Curio's Avatar
    Join Date
    Nov 2004
    Location
    London
    Posts
    899
    You have a startup entry somewhere that is pointing to desktop.ini. As ini files default open with notepad it is opening the file. If you download and run a startup editing program like autoruns from sysinternals you can look for the entry and modify/remove it.
    I'm using Windows 7 - you got a problem with that?

  3. #3

  4. #4
    Old and Cranky Super Moderator rik's Avatar
    Join Date
    Aug 2003
    Location
    Watching Your every move...
    Posts
    4,638

  5. #5
    Junior Member
    Join Date
    Nov 2005
    Posts
    21
    Quote Originally Posted by Curio
    You have a startup entry somewhere that is pointing to desktop.ini. As ini files default open with notepad it is opening the file. If you download and run a startup editing program like autoruns from sysinternals you can look for the entry and modify/remove it.
    Quote Originally Posted by Kane
    Many thanks to both Curio and Kane. I can only concur with Rik's comment, well done!

    Kane identified the definitive Microsoft article, but it does not say how the problem arose, ie where those pesky desktop.ini files came from.

    Microsoft's first suggestion, to delete the offending files, did not work, because the files were in use, presumably by Windows. The second suggestion did work, to use Msconfig.exe and untick the desktop startup entry for each user.

  6. #6
    Banned Aloone_Jonez's Avatar
    Join Date
    Dec 2005
    Posts
    58
    The desktop.ini files store information regarding the layout of the desktop or display options of a folder for example to arrange the icons in alaphabetical order.

    The reason why you normally can't see them is because Windows Explorer is hiding them from you but you can view another user's because their's aren't being used by Explorer. If you try to delete them Windows will replace them as it saves the default folder/desktop view options.
    You can also force Windows to show them for you from a folder windows choose Tools>Folder Options>File Types and uncheck "Hide protected operating system files"

    Really for security reasons (read to help protect you from viruses) all users should use limited accounts (this is even more important if they have Internet access), this also means that they can't see any other user's files unless you're the administrator, the only disadvantage is it breaks some old software - the choice is yours security vs backwards compatibility.

    [bitch]This is one of the annoying things about Windows
    [.ShellClassInfo]
    LocalizedResourceName=@%SystemRoot%\system32\shell32.dll,-21787

    wtf is -21787?[/bitch]

  7. #7
    Junior Member
    Join Date
    Nov 2005
    Posts
    21
    Quote Originally Posted by Aloone_Jonez
    Really for security reasons (read to help protect you from viruses) all users should use limited accounts (this is even more important if they have Internet access) ... the only disadvantage is it breaks some old software - the choice is yours security vs backwards compatibility.
    Thanks for your suggestion Aloone_Jonez. I've always been of the same opinion, and originally did have just one Administrator user.

    However, because some things did not work, I restored each user back to Administrator type.

    Following your comments, I'll have another try at having a single Administrator user with all 'normal' users restricted to Limited type.

  8. #8
    Banned Aloone_Jonez's Avatar
    Join Date
    Dec 2005
    Posts
    58
    What programs are you having trouble with?

    Providing they don't access the Internet (I wouldn't recommend using browsers/file sharing software like Imesh that insists on being as admin) it's moderately safe to create links to them with the runas command.

    http://www.microsoft.com/resources/d..._shortcut.mspx

    This also works in XP Home.

    For example if I want a open a command line with administrator privilages on my machine I create a new short cut on the desktop and where it says "type the location of the item" I enter the following:

    runas /user:Admin cmd

    You'll be promped for the password for the administrator account if you've set one which is a pain but I recommend it.

  9. #9
    Junior Member
    Join Date
    Nov 2005
    Posts
    21
    Quote Originally Posted by Aloone_Jonez
    What programs are you having trouble with?
    Two examples I came across today that do not work or have reduced functionality in a Limited account are:

    (1) Publisher 95 refuses to save any document with an error 'Publisher cannot create a temporary working file.'

    (2) Nero 6.3.1.18 does not show some of the selection icons, eg CD and DVD, and does not work to write to DVD.

    Your suggestion of using Runas works when selecting Run as for the normal desktop shortcut, but I could not create a specific Runas shortcut that works.

    I created the Runas shortcut by right-click on desktop, select New, select Shortcut, and type in
    runas /user: pc\superadmin :"C:\Program Files\Microsoft Publisher\MSPUB.EXE"

    Double-click on the Runas shortcut brings up a DOS window requesting the administrator user password, but nothing happens after the correct password is typed and Entered.

    The specific Runas shortcut does not save much time, but would be useful if there was also a way to save the password, so that the program runs without a need to enter the administrator name and password.

    [OT: I had to insert a space between : and p in the Runas command above, to stop that those two characters turning into a smiley . What's the proper way to prevent this smiley substitution, other than ticking 'Disable smilies in text'?]

  10. #10
    Bronze Member
    Join Date
    Dec 2005
    Posts
    176
    Quote Originally Posted by Aloone_Jonez
    runas /user:Admin cmd

    You'll be promped for the password for the administrator account if you've set one which is a pain but I recommend it.
    Quote Originally Posted by acc1
    The specific Runas shortcut does not save much time, but would be useful if there was also a way to save the password, so that the program runs without a need to enter the administrator name and password.
    You can run program as admin without having to type password using vb script. Copy and paste the following code into notepad and save with a VBS extension. Create shortcut to the script on the desktop of the limited account or other convenient location and change its icon . Since many anti-virus programs block VB scripts you may need to set it to allow this script. Change the dummy password with your admin password (Line:4) include the tilde at the end and add the full path of executable (Line:2). You can use environment variables (%WINDIR%, %PROGRAMFILES%....etc) in the file path.

    Code:
    set oShell= Wscript.CreateObject("WScript.Shell")
    oShell.Run "runas /user:administrator ""path of executable"""
    WScript.Sleep 100
    oShell.Sendkeys "youradminpassword~"
    Wscript.Quit
    Last edited by Kane; December 29th, 2005 at 17:48 PM.

  11. #11
    Nobody knows I'm a dog. TZ Veteran petard's Avatar
    Join Date
    Feb 2003
    Location
    Newspapastan
    Posts
    1,050
    Or hold down the Shift key, Right click on an icon, select "Run as..", then select Administator

    Many thanks to egghead for the cool .sig

  12. #12
    Triple Platinum Member Curio's Avatar
    Join Date
    Nov 2004
    Location
    London
    Posts
    899
    You could try Secure-IT from here http://www.sniff-em.com/secureit.shtml among the things it does is create some downlevel routes for running IE and OE as limited users without the need for passwording anything. It also hardens the local computer zone and quite a few other security tweaks - at the click of a mouse.

    Try it and if you don't like it - try something else!
    I'm using Windows 7 - you got a problem with that?

  13. #13
    Junior Member
    Join Date
    Nov 2005
    Posts
    21
    Many thanks gang for all your helpful suggestions.

    I'll persevere with using Limited accounts, and have a look at Secure-IT and Kane's vbs.

    Happy new year folks.

  14. #14
    Banned Aloone_Jonez's Avatar
    Join Date
    Dec 2005
    Posts
    58
    Kane,
    Last time I tried to do this I wrote a batch file to execute the runas command with a text file containing the password piped to the stdin, it didn't work for some reason.

    Is there a way to modify this script (VBS is new to me, batch files I know suck but are good enough to meet my normal needs) to accept a parameter?

    For example if I type runadmin program name at the cmd prompt or in a short cut it'll run the program as Admin.

    I've tried using %1 as a parameter to the runas command in your script as I would with a batch file but it didn't work.

  15. #15
    Bronze Member
    Join Date
    Dec 2005
    Posts
    176
    You can run scripts from the command line using Cscript.exe. Launch CScript and use the name of the script file (and its path, if required) as a parameter.

    cscript script.vbs

    The windows script host displays the banner (you can hide the banner using //NOLOGO parameter) and then executes the script. You can find out the syntax by typing cscript at command line.

    Launching a script file named, say, script.vbs, is equivalent to entering the following command in the Run dialog box

    wscript script.vbs

    The WScript host also defines several parameters that you can use to control how the script executes.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •