To punish me for my contempt for authority, fate made me an authority myself. – Albert Einstein
I.T.
Information Technology related posts
Windows XP allows a user to login and then it immediately logs out
Quite an odd thing happened today… I encountered the same very specific error twice on two completely unrelated computers (two different clients). In _both_ cases, clamwin had unnecessarily quarantined the following file:
C:\WINDOWS\system32\userinit.exe
On both machines, this occurred during a scheduled scan. The symptoms of this problem are that windows will allow the user to login, but it immediately logs out after a second or two. Here’s how I fixed it in both cases:
- Boot into the recovery console using a Windows XP install disk
- Select the windows installation experiencing the problem and type the Administrator password when asked
- Run the following command (assuming that your CD-ROM is D:\ and your hard drive is C:\):
expand D:\I386\USERINIT.EX_ C:\WINDOWS\system32
- Remove the CD from the drive then type ‘exit’ and hit ‘enter’ to reboot.
Once the computer boots properly (and allows you to stay logged in), use Malwarebytes, Spybot, HijackThis, etc. to scan your computer for viruses and/or spyware.
Update, 5 August 2009:
Just an additional note; you’ll want to be sure that the version of the file you copy from the installation disk is compatible with the service pack installed (it’s likely not). Symptoms of this incompatibility include things like explorer freezing when you try to shutdown or restart the computer. Uninstalling then Reinstalling the service pack should fix this issue. Alternatively, (and if ClamWin was the culprit) you could restore the old userinit.exe file from ClamWin’s quarantine directory… be sure to scan the file before doing this or else you could end up restoring an infected copy. So far, on every computer I’ve had to fix because of this (five and counting), ClamWin had falsely identified the userinit.exe file as a virus.
“Microsoft Document Imaging has encountered a problem and needs to close” When clicking on the ‘File’ menu
Error:
Microsoft Document Imaging has encountered a problem and needs to close
When clicking on the ‘File’ menu in Microsoft Document Imaging.
This problem has been around since at least office 2003. Lately I’ve been encountering it in recently updated versions of 2007, and by far the most straightforward way to fix it seems to be the following:
- Run regedit (‘Start’ -> ‘Run’, type ‘regedit’ and click ‘Ok’)
- Browse to the following registry key**:
HKEY_CURRENT_USER\Software\Microsoft\MSPaper 12.0\Recent File List
- Delete every value in the key (to clarify, delete all the values that appear in the right window).
From what I understand (from having to fix it in previous versions), there is a character limit on the file path of items that appear in the “Recently Opened/Used Files” portion of the ‘File’ menu. If a file whose path exceeds this limit (in previous versions it was 55 characters) appears in this menu, MODI will crash with the above error.
**Replace ‘MSPaper 12.0′ with whatever version you’re using; for example, office 2003 will be ‘MSPaper 11.0′
Outlook 2002 freezes when opening an attachment on a draft e-mail message
I still have a few users who use Outlook 2002. For the most part, they don’t have any reason to upgrade as it still meets their needs and I can’t justify telling them to spend ~$300 per user just to do what they’re already doing (sending/receiving e-mail… If I had my way, they’d all be using Thunderbird.) Today however, I encountered the following bug:
(1) User composes an e-mail (using word as their mail editor). The user also attaches either a word, excel, or powerpoint attachment to the message (tested with all three file types).
(2) User saves the message to drafts.
(3) A little while later, the user decides to finish writing this e-mail. They casually double click the attachment (in this case, a word document) link below the subject line and get the following message:
No big deal right? We’ve all seen this before. But there’s a problem! When they try to click on the ‘Open it’ option, Outlook is unresponsive. The only thing they can do at this point is kill OUTLOOK.EXE via the task manager. What makes this even weirder is that if the user re-opens Outlook, navigates to the ‘Drafts’ folder, opens the message and instead right-clicks the attachment, then selects ‘Open’ from the context menu, the problem does not manifest itself when the user tries to click the ‘Open it’ option on the subsequent warning message.
In this case, the user is accessing Outlook via a Terminal Services session, so upon being notified by the user that “my Outlook is frozen”, I login and take over their session. I do not notice a problem; I was able to click on the ‘Open it’ option just fine and Outlook was responsive. The user was happy that I fixed their problem and all was well… until it happened again. And again. So now I’m in WTF mode. I was able to recreate the error—it occurs whenever you (1) are composing a message with an attachment, and then double click on the attachment or (2) do the same thing from a message saved in ‘Drafts’. Right-clicking and selecting ‘Open’ _always_ works however. After googling for a few minutes, I came to the conclusion that this had something to do with “Advanced Text Services” so I disabled it, closed Outlook, logged out, logged in, opened Outlook, tried to recreate the error again and everything worked just fine!
To disable Advanced Text Services (in Windows XP/2003 … probably others):
- Click Start, then Control Panel.
- If Control Panel is in Category view, click the Date, Time, Language, and Regional Options link, and then click the Regional and Language Options icon.
If Control Panel is in Classic view, double-click the Regional and Language Options control panel. - Click the Languages tab. Click Details.
- Click the Advanced tab. Check Turn off advanced text services.
- Click OK. Click OK.
- Close the control panel
Or, if you’d like to disable this feature automatically (via domain login script), click here.
MAS 200 Error: “Unable to spawn a new session. The command line required for the server process is too long”
If you’ve recently moved MAS 200 data from one server to another, you might encounter the following error:
Unable to spawn a new session. The command line required for the server process is too long
There are a few things to check before calling Sage’s tech support:
(1) Permissions
Yep. Permissions. It’s a simple mistake to make and it’s easily resolved.
- Just navigate to ‘C:\Program Files\Sage Software’ (or wherever your MAS 200/90 installation resides.
- Right-click on the ‘MAS 200′ directory, select ‘Properties’.
- Select the ‘Security’ tab and select the ‘Advanced’ button.
- Make sure that the permissions are correct; if not, correct them.
- Then check the box next to: ‘Replace permission entries on all child objects with entries shown here that apply to child objects’
- Then click ‘Apply’.
- Click ‘Ok’ on the warning that appears.
- Click ‘Ok’ to close the window.
(2) If #1 doesn’t fix your problem, then clear the ‘Spawn Session from Application Server’ check box.
Note: Do not perform this step if the check box was selected to resolve connection issues, for example “Connection failure to host…”
- Expand Modules, Library Master, and Main. Double-click User Maintenance.
- Select the user ID.
- Click the Preferences tab.
- Clear the Spawn Session from Application Server check box.
- Click Accept.
- Repeat for each affected user.
(3) If the error still occurs, and the report is on the Custom Reports menu, the path and file name may be too long.
- Delete the report from the Custom Menu.
- Rename the file to a shorter name. Note: Try 55 characters or less for the entire path and file name. Some experimentation may be required. The exact length that causes the error is still being researched (as of v. 4.0)
- Add the report back to the Custom Menu.
If you are *still* having the problem then you should call MAS 200 tech support.
Moving data from ProSystem Fx Tax to fresh installation
Here’s the scenario:
(1) You’re about to upgrade your server (terminal server, file server, etc) and you’d like to copy all of your old ProSystem Fx Tax data to a new installation.
(2) You have a clean installation of the ProSystem Fx Tax software on the new server
Make sure nobody is currently running the program in either server and just copy the following directories:
c:\wfx32\Client c:\wfx32\Database c:\wfx32\officegr c:\wfx32\user
from the old (source) server, to the “wfx32″ directory (or whatever your installation directory for ProSystem Fx Tax is) to the destination server. If you have multiple years installed, you’ll want to ensure that the programs are all on the same version (as a precaution). This has been tested on version 2008.03000 and previous versions.
That should be all there is to it!
