Access Violation after Win-7 upgrade

[Ron E]

We have had several users, but not all, report getting the 'Access Violation ...in module Plsqldev.exe' after upgrading to Win-7 and Dev ver. 9.0.2. I suspect that it is due to increased internal security on their PCs (users can't write to any directories under C:\Program Files, as well as other areas.) Sometimes this occurs when first starting the program, but other times it occurs after running a query for several minutes. My guess is that it's trying to create a temp or setup file in a directory that the user can't write to. Oddly, sometimes after a couple reboots, the problem goes away for some people, which can make debugging somewhat difficult. So it hasn't been a major issue, but is a bit confusing.

I didn't see any option setting for temp workspace or other internal usage areas that could be changed.

Can somebody shed any light on where and when Developer might be trying to write, and if there are any alternatives?

Thanks

Ron

Most users have this version:

PL/SQL Developer
Version 9.0.2.1621
Windows 7 (64-bit) 6.1 Build 7601 (Service Pack 1)

We install both 32 and 64 bit Oracle ver.11.2 drivers

 

[T-Gergely]

Access Violation shouldn't be ACL (security as you write) related. It's mostly due to incorrect use of pointers. PSD tends to do that after an (unreported) RDBMS error (mostly XMLTYPE related for us). I'd trace the sessions (preferably on the clients) and see if any unexpected ORA- error occurred.

In theory, it could be ACL related incorrect pointer handling (lack of error checking), but the term violation doesn't imply that.

 

[Marco Kalter]

Is there a plsqldev.elf file referenced in the error message of the access violation? If so, can you send it to me?

 

[Ron E]

No. The error box that pops up says just 'Error' in the title box at the top, and I/O error 183 (which is a Windows 'no access' message, I'm assuming). When you click on OK, you get "Access violation at address 00406490 in module 'plsqldev.exe'. Read of address 742E745D. The results display has column headings, but all the values are blank.

I just had him try it again, and this one hasn't gone away like some of the others. The query is a simple SELECT with one join, but using PARTITION (...) after each table name. Nothing fancy although even one partition of this table is likely to be several hundred million rows.

Ron

 

[Ron E]

Is it possible that there's a .elf file and not be noted in the message? If so, where would I tell him to look for it?

thanks

Ron

 

[mike]

My elf files always go to the directory where plsql developer is installed. For example C:\Program Files (x86)\PLSQL Developer

 

[Ron E]

Mine was there, so I had him look, and no ELF file. So I had him try to save a text file there, knowing that most of our users don't have write permission to anything under the Program Files directory, and he could save there. So that's apparently not where Developer is having trouble writing to. Surely somebody should know where it writes its TEMP files, so we would have some place to start looking.

Ron

 

[mike]

I had problems when I upgraded to Windows 7 because of security. I needed to go to the directory where PL/SQL Developer is installed, right click on the executable (plsqldev.exe), select properties, select the compatibility tab, and then check "run this program as an administrator". Then it worked.

 

[Marco van der Linden]

Having a similar problem since this morning (after a windows update). Sent the elf file to support.

 

[Hilarion]

The problem comes from combination of three factors:

1. Windows 7 has a layer of security called User Account Control (UAC; introduced in Windows Vista) which effectively strips some rights from user unless you explicitly state you want to run a process with full user rights. For backwards compatibility is combined with disc and registry access virtualization (so from application point of view it is still able to add/modify files or registry key/values where it does not have required rights).
To remove this factor you can either run applications with elevated (full) privileges or turn off UAC (this is per user setting and may require system restart for change to be fully effective).

2. Current PL/SQL Developer version is partially UAC-aware application, so Windows does not use disc/registry access virtualization for it. This is good and bad. Good, because PL/SQL Developer can really check if it has rights to modify some files/folders and it's modifications will never land in virtualization folders (a bit hard to find if a user wants to access them directly for example to back them up or move them to new machine).

3. PL/SQL Developer tries to store user preference files in the folder where the application is stored but if it can't then it uses user profile folder for that purpose (the order of the checking may be reversed in new PL/SQL Developer versions but AFAIK it did not). The problem is that if it was able to store user settings in application's folder (it did create user preference files there), then it will try to continue to do so even if user lost his rights to modify those files/folders.

If you just have made a clean install of PL/SQL Developer on Windows 7 machine and have not launched it yet, then you can prevent all those factors to affect you by modifying "params.ini" file of PL/SQL Developer prior to first use.
What you have to do is add (or rather uncomment and modify) an entry that tells PL/SQL Developer where it should store user preference settings and set it to user profile subfolder like this:
prefpath=%APPDATA%\PLSQL Developer\Preferences\

If you already have used the application, then things may get trickier. If you had UAC turned on from the very first application use and used only relatively new versions of PL/SQL Developer, then your preference files may already be in the correct location (user profile folder). You should however verify that. What you should check is "Preferences" subfolder of the application folder (usually "C:\Program Files\PLSQL Developer\Preferences" or "C:\Program Files (x86)\PLSQL Developer\Preferences"), profile "PLSQL Developer\Preferences" subfolder (something like "%APPDATA%\PLSQL Developer\Preferences") and virtualization subfolders (something like "%LOCALAPPDATA%\VirtualStore").
If your files are not in correct/safe place (your user profile only), then moving them where they should be is tricky (as there are cross-references to full file paths in those files) and it may require merging files (if you got hit by virtualization).
Only after you correctly move preference files to correct locations, it's safe to modify "params.ini" (otherwise you may end up loosing some or all preference settings).

 

[Ron E]

Thanks for your excellent explanation. I wish I had had this available several months ago when this problem first started driving me nuts.

It turns out that we have two problems, which have very similar errors, but aren't caused by the same thing. One is what you note - Our users aren't allowed to change any files under Program Files (or the x86 version). Normally Developer handles this fine. But occasionally after a Win-7 install, one of the installers forgets to change the permissions from his Admin ID to the owner's ID, so the owner can not only not write to the Program Files folders, but not to his own set of folders either, causing the issue in one instance.

One of our more enterprising installers apparently asked a more pointed question of Support than I have, and got a different answer. There is apparently a bug in version 9 which causes Developer to also not handle temp files correctly sometimes, also leading to the error. This apparently requires a registry change to fix, and is apparently also fixed in version 10.

So now we know that if the trouble isn't one place, it's the other, and both are easily fixable.

Thanks also to everybody who made suggestions. That's one reason we still prefer this product after all these years.

Ron