When isn't a File Write Permission? When its SP3?

I've been working a lot lately on a project that as part of its functionality writes over or deletes files in a sub-folder in the Program Files folder in Windows XP Pro. Trying to delete the files or overwrite them using a VB.Net program written using VS2005/SP1 throws an exception error. The program has a local signed certificate in a totally trusted mode. If the files don't exist, the program can easily write them as new files without an exception

The user logon at both times (during the previous “rename-the-computer” boot and the “current” boot-up) are the same logged-on user who's an Administrator group member. Just the local “domain” name, the computer name has changed. The users have remained the same, the file permissions and the group permissions have remained the same etc.

In all cases, the computer has remained in Workgroup mode. There has been no attempt, at any time, to join a NT or Active Directory domain performed on the computer OS image load.

DEP is on only for Windows OS files.

The OS image starts out as a ghost image, that was a SP3 slipstreamed volume license of Windows XP Pro SP1. In other words, its running as a Windows Pro SP3 system. It operates just fine, no errors, no BSODs etc. You've already heard about the Router-SP3 Hell.

The specific files to be deleted or overwritten are application configuration files with an .ini extension. A hold-over from MS/DOS & Win95 days, these files are used in the proprietary application to configure the ODBC handle used for COM data connectors. They are typically set as read-only. What makes it aggravating is that even if the files are set as read-write, they cannot be deleted or overwritten using the VS2005 VB.Net program even when the files are setup initially as NOT read-only.

The applications are installed using an application that maps a before and after image of the system and creates a difference file executable that “installs” the corporate applications.

I've already determined that if I change the files ACL by using VBScript (5.6) to read-write, the VS2005 VB.Net program will work without throwing an exception.

If I change the read-only permission to read-write using Windows Explorer properties applet, the VB.Net program works.

Here's the one that takes the cake, if I run the VB.Net program on an image created with SP2 slipstreamed onto the same volume license image, the VB.Net program works! Even with the files set as read-only. No exception errors.

So what changed in SP3 to break VS2005 VB.Net?