This content has been marked as final. Show 4 replies
Did you originally have reader installed on the E: partition when it was your original Windows XP? I'm not sure how you did your install, but if you did some sort of copy/restore from an old drive to a new drive, Adobe might be looking at the original install location and trying to execute it from their. I know when Window's expects a file to be in a certain place and doesn't see it, it will run a search to try and locate it. If it finds it in the search, it will update the locations or shortcuts to where the files are located.
Well, originally reader was installed on the first partition, and at the time of installation the first partition was designated as C:. Then everyhing was copied to the second partition, the second partition was booted into, at which time the second partition became C: and the first partition became E:. So there is an identical installation in both C:\WINDOWS and E:\WINDOWS, so there is no problem finding the files on C:\WINDOWS.
(It's sort of confusing, but it is the basic idea of OS cloning: whichever partition you boot into should become the "active" C: partition, and any copies on other partitions should be untouched, as if they were not there. So sometimes the first partition is C: and sometimes it is E:, depending on which one you are booted into.)
Now, I went into the master boot record and deleted the first partition entirely, so that only the second partition exists. Then I booted into the second partition (as C:) and guess what? Adobe was using the files on C:\WINDOWS. So if the first partition is visible, it uses the first partition, but if the first partition is not visible it uses the second partition.
That's really weird, because software isn't normally aware of absolute partition locations; software is usually only aware of drive letters, and if Windows changes the drive letters, the software should use whatever Windows says is C:, regardless of which partition C: is on.
OK well I think I may have figured out what is going on. I used the tools "handle" and "autoruns" and they kept showing that no files on the E: drive are actually in use.
It looks like it has something to do with NTFS permissions. Windows will say "you don't have permissions or the file is in use". I usually assume that I have permissions, and that this means the file is in use. But apparently not.
So it looks like the problem (which is really not a problem at all) is that the dll files are in a directory with some rather unusual permissions on them, which makes it look like they are "in use" even when they are not. Still strange: reader and flash are the only files out of thousands that do this.
I have installed Adobe Reader 9 on Windows XP(sp3).
When an attempt is made to programmatically access text in pdf files calling the default dll (AcroRdIF.dll) at times, randomly, the call generates an error. The Visual Studio 2008 error message generated is:
"The runtime has encountered a fatal error. The address of the error was at 0x012b065d, on thread 0x169c. The error code is 0x80131623."
If I install PDF IFilter 6.0 after installing Reader 9, the default dll (PDFFILT.dll) for it replaces the Reader 9 dll.
There are no problems at all with the IFilter 6 dll.
This suggests that there is a stack overflow problem in AcroRdIF.dll which is apparently randomly triggered - files which sometimes generate the error, at other times are read correctly.
Is there an update to the version of AcroRdIF.dll which comes with the current download from Adobe?
If not, is this problem being addressed or should people who use pdf text reading software be advised to continue downloading and installing PDF IFilter 6.0?