TrickyLuck

Hi, I know this is going to sound unbelievable but I have a Inno Geforce 4 MX440 AGP 64 meg and I can not believe that it takes everything that I throw at it?? I have Painkiller, Doom 3 and XIII and haven't really had many problems. Ok, with the huge monsters in Painkiller it does slow down when you have the monster in view but it doesn't make it totally unplayable. Because Doom 3 is all in small corridors with generally small expanses of playing areas it copes amazingly well. I have a Gigabyte motherboard can't remember exactly but it's a 7VXP or something like that. My mate has the same specced system but on a MSI motherboard and mine must be at least a third maybe a half quicker than his! I only have a lowly 1600XP+ in my system with 512 meg of memory but it works a treat!! I do, however have a quick and new extra harddisk, I would suggest if the game is choppy this is where your problem is more likely to lie, go out and get yourself a new harddisk and see how you go, As always, let us know!!! Cheers Tricky_Luck

Right... sorry for the long delay, had a nightmare with this one but wanted to make you guys aware, this is VERY Valuble information. I know we skipped onto ACT and I should have put this in the apps forum but this information is now system related. While in relation to ACT and finding out why Write wouldn't fire up I was left at our last conversation going through REGMON and FILEMON. I noticed that the users didn't have CreateKey access to HKEY_CLASSES_ROOT when trying to run Write. So, I added my test user giving full permissions using regedt32 (on a live terminal server) to HKEY_CLASSES_ROOT top of the tree, just for testing. Disaster then insued.... If you ever think of adding anything to the HKEY_CLASSES_ROOT, just.... don't It Removed every one of the system permissions that were there originally and gave my test user full access rights (as I had asked) and gave everyone else Read access only. ALL OTHER PERMISSIONS WERE GONE. No I didn't take any ticks out of any boxes or put any ticks in any boxes I just added my test user. I thought I'd add the permissions back manually and this bought up a box saying something like , can't display user list (NULL) Oh...... dear...... I thought (I have read your terms and conditions on posting!!) At this point I noticed that the Inherit permissions box was unticked so I put the tick back in and clicked apply. It went away and seemed to be doing something but came back and removed the tick from the box... oh.... eeeeerrr ..... dear... I thought again. After returning from the WC and using copious amounts of air-freshener the customer called to say that the server, if they logged off their terminal services session, couldn't sign back on again they got a cursor and a blue backdrop. The next question was where the hell was it inheriting from, it's at the top of it's tree, AAARRGGGGHHHH.... ;( To cut the rest of this long story short, the HKEY_CLASSES_ROOT looks like it is some kind of virtual like to HKEY_LOCAL_MACHINE>SOFTWARE>Classes If you go to this location and reset and reapply inherited permissions it resets everything on HKEY_CLASSES_ROOT It looks like this is a serious bug to me. When changes are made to the head of the HKEY_CLASSES_ROOT it is almost like it looses this "virtual link" and gives permissions to the entry you added and read access to everyone else. This only applies on a Domain Controller. The interesting thing was that when the user ran ACT with the full permissions the Write program from within worked, so I was on the right lines, just our Mates at Microsoft leaving leaves and twiggs covering a whacking great hole full of the days chemical toilet for us to fall into.... thanks for this one!!! DON'T USE THE ABOVE SOLUTION FOR GETTING WRITE TO WORK WITHIN ACT... it worked for a day and then because we put full permissions for everyone on this key as they were all using ACT something else got screwed that stopped Office shortcuts on the desktop running but would allow you to run the executeable.... but THAT... my friends is another story..... I hope this will help someone in the future, and I hope this is a useful addition to your excellent forum. P.S, Microsoft, Dell, HP and all the other forums we found said that this situation called for a reload, I believe that this is the first openly available forum to actually give an answer on this Thanks again for all your input, Regards Tricky_Luck

Hi Adam, Sysinternals is exactly what I have been using, brilliant set of tools, recommend Process Explorer too, can see the ACT process running and can right click and see security permissions AND privileges, so have been playing with NTRIGHTS this afternoon, not to much success it has to be said :0( The Sysinternal programs are great but still requires a lot of work, and yes, it is a Domain controller. I have taken on board your points about the all users and will continue to dig through with Sysinternals, Thankyou, I'll let you know how I get on tomorrow... what a pain!!! Cheers Tricky_Luck

Hi Adam, The reason for this request is that we are trying to get ACT working on a Windows 2000 Server 1) ACT is not officially supported in a Terminal Services environment but we have other customers using it fine. 2) The version of ACT was installed fine until we tried to run Write (ACT's Word Processor) which bought up security errors 3) Our ACT Guru said that this was because in a Terminal Services environment it needs to be installed as the LOCAL Administrator to make sure all the users get the right permissions. 4) I presume that this is why ACT recommend putting their software on a different server altogether. I know that this is related to Terminal Service and ACT and should be in the applications section but I didn't mention, or feel that I needed to mention this in relation to the immediate problem but you did ask!!! ;0) I have been playing with APK's suggestions and may have found another area where the problem with ACT may lie, without having to sign on locally. Once I am definate about my resolve I'll post it in the applications section and let you know here too. This has been my first days worth of postings here and this seems an excellent resource for some rapid answers. Thanks again to all contributors. Tricky_Luck

Hi APK, Thanks for the rapid response, I know GINA can be a bit of a pain (past experience) so am petrified going anywhere near that!! I'll take a look at the other options you have given and let you know, Thanks again Tricky_Luck

Hi, I am confused.... We have a Windows 2000 server on a Domain that I need to logon locally to. Everything that I have read refers to users not being able to logon to the local system, this is a bit different, let me try to explain. From the console of the machine I can sign on as Administrator and to the DOMAIN but there is no dropdown box to allow me to logon to MACHINENAME. I need to sign on to the local MACHINENAME but I can't even choose it at this point to even attempt to login, so I have no error messages or anything I can give you, Any help or pointers to links that maybe useful would be appreciated, Thankyou all! Tricky_Luck

Hi, I am confused.... We have a Windows 2000 server on a Domain that I need to logon locally to. Everything that I have read refers to users not being able to logon to the local system, this is a bit different, let me try to explain. From the console of the machine I can sign on as Administrator and to the DOMAIN but there is no dropdown box to allow me to logon to MACHINENAME. I need to sign on to the local MACHINENAME but I can't even choose it at this point to even attempt to login, so I have no error messages or anything I can give you, Any help or pointers to links that maybe useful would be appreciated, Thankyou all! Tricky_Luck

Hi, AlecStar has given you some great tips there, after doing the service pack upgrade to IE I would expect this to fix it. If it doesn't I'd suggest the following. Get your Windows XP cd in the CDROM drive and go to a command prompt by either finding it in XP's maze of programs or clicking Start and going to RUN Within this box type cmd You will now get a black box where you can type the following command. This command will restore files back to their defaults and replace missing files. Please be aware that I have not had a problem with this method but if you have third party software it may need reinstalling if this XP recovery procedure overwrites a more up to date dll, you may want to run Windows Update again after doing this. As always, I accept no liability for any unforseen damage this may do to your operating system or third party software. As I say, I have never had a problem running this and it has saved me on a number of occasions. Within the DOS box type sfc /SCANNOW Your missing files will be restored, this will take a good while so be patient. Let us all know how you get on Cheers Tricky_Luck

Are you trying to overclock??? Make sure that your CPU voltage is the same as you have your motherboard and BIOS set to to start. pin bab Minidumps are usually hardware related tho, make sure your CDROM that you are installing from is not clashing with your hard disk. Make sure the primary is your hard disk and your slave is set as the CDROM and they are not on CSEL as this could cause it. Some types of CDROM require an 80 cable rather than a 40 and when it tries to spin up to read max it may fail if your not using the right cable. Sorry if this is a bit rushed, I actually came on the site to check for something else but thought this maybe helpful???