Can't install net.framework 3.5 - weird ...

I am having this bizarre problem when I try to install net.framework 3.5. I have tried to install it a number of times with no luck, and when I try to check the error log nothing comes up. I googled the problem and made sure there were no obvious problems (e.g. - IIS is activated). I tried to install using the more comprehensive "dotnetfx35.exe" install file. That when I realized it was extracting to another partition which was not even on the same hard drive!! I thought maybe it was because I was installing from a partition other than C, so moved the file to C & tried again. Same problem, except this time it extracted to yet another partition, again not even on the same hard drive. I have not had this problem with any other version of net.framework. I am running XP Pro SP3.
Thanks

 

have you tried to get it through windows update? not sure if it's an option, but it should install it correctly that way.

 

This may be totally off-base for your situation, but I encountered the 1603 error code in the .NET install log (noted to be a very generic error) while trying to install AutoDesk Revit 2010 for a client. After trying the "full" redistributable packages of .NET 3.5 and .NET 3.5 SP1 from download.microsoft.com and getting the same error, I checked the system event log on the workstation having the problem (WinXP Pro SP2 in an Active Directory environment). The error logged there mentioned something about a lack of permissions for a particular DLL file in the path C:\PROGRAM FILES\REFERENCE ASSEMBLIES\... [truncated]. I looked at Security permissions and found that Users did not have full permissions, and that the Administrator account (local or AD) had absolutely no permissions (not even READ permissions) on that folder or sub-folders and files. Further, I checked the permissions level for the Administrator account and found that, for some reason, the Administrator account on this workstation was not a member of the Administrators group, but was in the "Debugger" group.

My shotgun approach was to reset group for Administrator account to "Administrators," and to give the Administrator account full rights to the folder structure mentioned in the event log.

Hopefully, this will help someone stumbling upon this post in search of a error 1603 solution.