WXP Locks up on Loading Personal Settings if default input language is Japanese

Windows XP SP2.  System language is set to Japanese (this is Language to use for non-Unicode programs on the Advanced tab of the Regional and Language Options).  Available input languages are English and Japanese.

If a user sets the default input language to Japanese (Japanese-Microsoft IME Standard 2002 ver 8.1)  the computer locks up on "Loading your personal settings" when he/she tries to login.  

*  If the user is a member of the local administrators group, this problem does not occur.  
*  If the user has English selected as the default input language, this problem does not occur even if the user is NOT a member of the local administrators group.
*  If the system language (language used for non-unicode) is English, this problem does not occur even if the default input language IS Japanese and the user is NOT a member of the administrators group.
*  This problem did not occur on Windows 2000.

I can make this problem occur on a variety of hardware (desktops, laptops, etc) and with any user id  (e.g. domain user account,  local user account).  So it does not seem to be hardware related and it is not a corrupted user profile.

So my question is,  what is running on WXP only when the default input language is Japanese and the non-unicode language is Japanese that requires a user to have administrator rights during login?
atniscoAsked:
Who is Participating?
 
poseidoncanuckConnect With a Mentor Commented:
Very nicely done!  Narrowing the problem down to this one specific access that's failing is a major accomplishment (especially when using Process Monitor for the first time).

I would've expected all Registry keys under HKU\.Default (aka HKEY_USERS\.DEFAULT) would allow at least "Read" access for all members of the local Users and Power Users groups.  [I don't have any entries under HKU\.Default\Software\Microsoft for anything labelled IME**, so I can't be sure that key is supposed to be this way too, but I would be surprised otherwise.]

Could you check two things?

1. What are the group memberships for the user in question?  Run the GPRESULT.EXE command from a command prompt and examine the entries under the heading "The user is a part of the following security groups:".  If you don't see BUILTIN\Users among the listing, then there'd definitely be a problem.

2. What are the permissions assigned to the Registry key you've identified?
- Launch Regedit.exe (Start, Run, "regedit.exe")
- browse to that key i.e. HKEY_USERS > .DEFAULT > Software > Microsoft > IMEJP > 8.1 > Dictionaries
- make sure you've highlighted the Dictionaries folder on the left-hand side, then go to the Edit menu and choose "Permissions..."
- click the Advanced button, and examine each of the Permission entries.  You're looking for the Permission corresponding to the Users group, and what it has listed under the "Type" and "Inherited From" columns.

As I said, I'd have expected the entry for Users to show "Read" under the Permission heading, "Allow" under the Type heading, and something like "USERS\.DEFAULT" under the Inherited From heading.

What do these investigations tell you?
0
 
poseidoncanuckCommented:
I don't know the root cause of this, but I am fascinated by the fact that success or failure can depend on whether the user has admin rights or not.  That, plus the fact that it doesn't occur when the other language settings scenarios are in place, leaves me convinced that there's a permissions problem, and that it's just a permission on one or a handful of very specific files that are used only by the per-user Japanese input language.

Sysinternals' Process Monitor is the king of all FREE tools to uncover hidden permissions issues (as well as a number of other uses).  It will let you log all file, registry and process activity for all processes, and you can even configure it to do boot-time logging (so that you can be sure you're capturing the activity that occurs during logon).

You'll need a little patience and persistence, as this tool will log a LOT of data.  However, if you get familiar with the tool, and you search through the logs for any ACCESS DENIED errors, you'll eventually track down exactly where the problem lies.

Get a copy of Process Monitor here:
http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx

Set it up like this:
- logon as an admin and launch PROCMON.EXE
- go to the Options menu and click on "Enable boot logging"
- go to the File menu, choose "Backing Files" and select the "Use page file" radio button
- reboot
- logon as the non-admin user account that has enabled Japanese as the default input language
- wait until it halts at Personal settings, and then do whatever you usually do to log back on as an admin user
- Re-launch Process Monitor, and when it asks you if you want to save the logged information, say yes and choose a local folder to save the log file.
- Finally, go to the Filter menu, choose "Filter..." and do the following to narrow down the log to just the ACCESS DENIED entries
--- in the first drop-down menu, choose "Result"
--- in the second drop-down menu, choose "is"
--- in the third drop-down menu, choose "ACCESS DENIED"
--- in the fourth drop-down menu, choose "Include"
--- click the Add button, then click OK, and start looking through the entries for anything that looks like it might be related to your scenario.

If you have trouble, try its help file, and if you really need help, check their online Forum (http://forum.sysinternals.com/).

Good luck, and let us know how it goes.
0
 
atniscoAuthor Commented:
Process monitor shows:

Process: winlogon
Operation: RegOpenKey
Path: HKU\Default\Software\Microsoft\IMEJP\8.1\Dictionaries
Desired access: Maximum allowed

This line is repeated over and over and over again...so I suspect this is the culprit.  I don't really understand what I need to do in order to "fix" it though.  
0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
atniscoAuthor Commented:
The users in question are members of "users" and "power users".     As it turns out,  the Permissions are as you would expect down to the "8.1" level.   (Users and Power users have Read access and it is inherited from USERS\DEFAULT).    However,  the keys below the 8.1 level  (e.g. Dictionaries, Dictionaries64, Manage, and various others)  all had different permission.  They all show Administrators, Restricted, and System having full control, not inherited, this key only.    So obviously,  users and power users no longer had any access.    

I was able to solve the problem by clicking the box from the "8.1" folder "replace permission entries on all child objects with entries shown here that apply to child objects".    This put the read permission for users and power users back on the dictionaries, & other folders below the 8.1 folder.   Now the users can login w/o any problem.

The strange thing is,  the folders below HKU\DEFAULT\Software\Microsoft\IMEJP\8.1 do not exist on all the computer that have selected Japanese as default input language.   It seems that these folders only get created when some "event" happens...I suspect when certain printers are installed.  

At any rate,  process monitor helped me find what was locking up the user login, and your instructions regarding registry permissions helped me make adjustments that solved the problem.  Thanks!
0
 
BabbelasCommented:
Hi Atnisco

Have you ever discovered the root cause of this?

Thanks
0
 
atniscoAuthor Commented:
No, I still have not discovered the root cause of the problem.   However, something happens when the Japanese scenario (as described above) creates various dictionary folders below the IMEJP\8.1 folder.  They are created w/o the correct default permissions.  I've never been able to narrow it down to anything more specific than that.
0
 
BabbelasCommented:
Thanks for that!
After you fixed the permissions did it come back?
0
 
atniscoAuthor Commented:
No.  Once I fix the permissions, the problem has been resolved.  However, I have had the same problem on several computers.   I have to wait to "fix" it until someone encounters the problem on each particular computer.   So far I have not found a way to proactively prevent this issue.
0
 
KoohiisanCommented:
Just to add: we have had this issue on a couple of systems here, and I think I may have found the trigger.  It seems to be effective as soon as we change the default language for non-unicode programs to Japanese.  At that point, any existing user-level sign-on with Japanese as the non-unicode system language hangs at the "Loading Personal Settings" point.

HTH.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.