- This blog will NOT be updated regularly
- This blog will NOT necessarily have technically correct info (it just worked for me)
Saturday, August 11, 2007
Intro
Hello all, just a very brief intro on what you will find on this blog. Contents will be nerdy notes from my nerdy work as a consultant on practically anything that has to do with computers, in addition to the occasional note on technology related hobbies. It is supposed to work as an easily accessible brain dump to get back to the next time I encounter the same problem again. Use it if you like, comment on my posts if you like, but please note that:
Wednesday, May 30, 2007
Event: i8042prt failed to start
On an HP Proliant DL 380 G5 server with Windows 2003 Server, the annoying "A device or service failed to start" occurred during boot. The computer shared screen, mouse and keyboard with another computer via a KVM switch. Event log showed a "i8042prt failed to start" event.
The solution was found on HPs support pages. In brief, it states that the following regkey must be changed:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters
The value Headless must be changed to value 0x1 (REG_DWORD)
Data: 0x1 (Allow Hotplugging) | 0x0 (Hotplugging not allowed)
Problem cause (assumed): This happens when the computer boots without finding any keyboard/mouse. This occurs when the computer is connected to a KVM switch and the KVM serves another computer during boot.
The solution was found on HPs support pages. In brief, it states that the following regkey must be changed:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters
The value Headless must be changed to value 0x1 (REG_DWORD)
Data: 0x1 (Allow Hotplugging) | 0x0 (Hotplugging not allowed)
Problem cause (assumed): This happens when the computer boots without finding any keyboard/mouse. This occurs when the computer is connected to a KVM switch and the KVM serves another computer during boot.
Monday, May 21, 2007
Ni-DAQ test panel does not run
Platform: Windows Server 2003 with NiDaq 8.0
User is not allowed to run test panel under Ni-Daq's "Measurement and Automation" (the choice is grayed out). A program that uses Ni-Daq's libraries terminates silently with user credentials. Both problems are related.
Solution: Users who want to be able to run the above mentioned programs must be given Modify or Full control permissions on this folder:
It took a lot of research and experimenting with permissions on files and registry keys to reach this conclusion, but it seems consistent that this was the problem.
Caveat: When connecting to the server via Remote Desktop as a user, I was not allowed to run the test panel or other programs using the Ni-Daqs libraries, even if the above solution was applied. Being an administrator, I was allowed. Researching the problem via Remote Desktop at first certainly put a few extra hours of work into finding the solution :(
Caveat 2: On older NT4 systems this will probably not be a problem, because it does not restrict the permissions on C:\program files to readonly for standard users (by default).
Caveat 3: On older Ni-Daq versions (ver. 6.9.1 comfirmed), the above mentioned folder does not exist. Whether that means that the problem is then irrelevant or to be solved differently is not known.
User is not allowed to run test panel under Ni-Daq's "Measurement and Automation" (the choice is grayed out). A program that uses Ni-Daq's libraries terminates silently with user credentials. Both problems are related.
Solution: Users who want to be able to run the above mentioned programs must be given Modify or Full control permissions on this folder:
C:\Program Files\National Instruments\Shared\platform\memory\sharedMemoryFiles
It took a lot of research and experimenting with permissions on files and registry keys to reach this conclusion, but it seems consistent that this was the problem.
Caveat: When connecting to the server via Remote Desktop as a user, I was not allowed to run the test panel or other programs using the Ni-Daqs libraries, even if the above solution was applied. Being an administrator, I was allowed. Researching the problem via Remote Desktop at first certainly put a few extra hours of work into finding the solution :(
Caveat 2: On older NT4 systems this will probably not be a problem, because it does not restrict the permissions on C:\program files to readonly for standard users (by default).
Caveat 3: On older Ni-Daq versions (ver. 6.9.1 comfirmed), the above mentioned folder does not exist. Whether that means that the problem is then irrelevant or to be solved differently is not known.
Subscribe to:
Posts (Atom)