Nvidia DDS Plugin "access violation"

[Khuri]

I've recently upgraded to PSP X5 and tried to update to the latest nvidia 32 bit DDS Plugin today (this one).
After the installation i copied the "dds.8bi" file in my "PlugIns\EN\" folder - which worked perfect with previous versions (my latest was from 2011 tho).

When i try to save a DDS file i get the normal DDS export/configuration dialog. When i hit save, i get an error message stating that the plugin causes an access violation (in german: "Plugin hat Zugriffsverletzung verursacht").
That error message appears twice and the file is of course not saved.

Any advice what the error means and/or how to get the plugin running is greatly appreciated.
Thank you!

[LeviFiction]

Have you tried running PSP as Administrator? Right-click on PSP's icon and select "Run as Administrator" from the menu. This is important because Administrator accounts in Windows don't run programs with Administrator privileges. You have to specify that yourself.

If that works then it might be because it's inside PSP's Program Files folder. If that doesn't work....then the rest of this post is useless to you.

You could try creating a new Plugins folder in you My Documents folder.

Add a new "Plugins" folder to your My Documents or PSP user files. (i.e. C:\users\My Documents\Corel PaintShop Pro\14.0\Plugins)

From the file menu go to Preferences then choose File Locations.

Under Plugins add in the folder you just created.

Move the plugin in there. I can't guarantee it will do any better but the first thing that pops into my head when I see that error is you've placed it into the Program Files folder for PSP. And Windows doesn't like it when you try to write files or edit files in that location. So the plugin is trying to do something odd and can't because of permissions problems. Highly unlikely that that is the issue but always possible.

[photodrawken]

Administrator accounts in Windows don't run programs with Administrator privileges

Point of order: they do. See this MS document:
http://windows.microsoft.com/en-US/wind ... or-account

The User Account Control: Admin Approval Mode for the built-in Administrator account policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account.

The options are:
•
Enabled. The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.

•
Disabled. (Default) The built-in Administrator account runs all applications with full administrative privilege.

(Emphasis added.)

[Khuri]

Thanks for your suggestions, but neither works.
As photodrawken pointed out, being logged in as administrator also runs applications with those priviledges, so it's not that.
I tried the odd "move plugin to another folder" test, but the results are sadly the same (would've surprised me as well, with the application running with administrator priviledges already - but you never know).

As for other versions, of course i am running X5 with the SP 1 patch and my nVidia drivers are also latest (310.70).

Other suggestions are welcome.
Maybe someone could download the DDS Plugin i linked above and try for themselves?
To try out, after installing/copying the plugin you just have to save a file as DDS, leave the options as they are and hit save.

[Khuri]

I just tried a slightly older version (8.51, above is 8.52) which works flawlessly.
Still, if anyone figures out or has ideas why the latest one does not work, i'll be happy to try out suggestions

[LeviFiction]

There is the Administrator Account, and the Administrators group. Forgive me, I didn't make the proper distinction for you.

The Administrator account is Windows closest equivalent to Linux and Unix's Root account.

All other users are members of the administrators group. You think of them like sudoers in Linux. Capable of running Admin level privileges but not by default.

That article you found was for the default disabled Administrator Account. An account most people don't know how to turn on, much less ever do. Microsoft hid this account as protection against programs running with administrator privileges without your consent. So the default account you setup when you first setup your computer is in fact a standard user that is part of the administrators group, not The Administrator account. Simply being in the Administrators Group does not auto-run programs with Administrator privileges.

Glad you found an option that works for you though, haven't a clue as to what that error could be referring to.

[photodrawken]

So the default account you setup when you first setup your computer is in fact a standard user that is part of the administrators group, not The Administrator account. Simply being in the Administrators Group does not auto-run programs with Administrator privileges.

Got a citation for that?

[LeviFiction]

This has been true since Vista. But to humor you I did a quick search on Microsoft's forums. Since it doesn't list anything in the support site you pointed to.

http://answers.microsoft.com/en-us/wind ... 31b?auth=1

[photodrawken]

This has been true since Vista. But to humor you I did a quick search on Microsoft's forums. Since it doesn't list anything in the support site you pointed to.

http://answers.microsoft.com/en-us/wind ... 31b?auth=1

That citation only refers to accessing the built-in Administrator account, and not whether programs run under an administrator's account run with full administrator privileges, which I contend that they do.
Not being just argumentative here, but I'd like to see some definitive documentation about this, since the question does come up now and then.

[LeviFiction]

EDIT: No matter how many times I edit this, this reply never seems to get any shorter. I hope this helps to explain the situation a little.

I feel that forum topic does give enough information to definitvely say that the Administrator group is different in functionality from the Built-in Administrator account.

But you're right it doesn't explicitly say that Administrator users act differently. Lots of implications and implied statements but nothing explicit. And I full acknowledge I'm finding many posts online that suggest the difference but no definitive documentation from Microsoft listing those facts. I don't know if I'm just searching incorrect terms or what. But I'll keep searching.

I did, however, find something that you might find interesting.

UAC: Admin Approval Mode
http://windows.microsoft.com/en-US/wind ... roval-Mode

Built-in Administrator Account UAC Admin Approval Mode
http://windows.microsoft.com/en-US/wind ... or-account

Both of those articles are about Admin Approval Mode. For the UAC Admin Approval Mode is Enabled by Default. For the Built-in Administrator Admin Approval Mode is Disabled by default. That if you disable AAM the UAC is also turned off.

In my link to the Forum Topic they mention specifically that the Built-in Administrator turns off the UAC by default. Which matches the articles above. If the UAC needs the AAM, and AAM is disabled by default for the Built-in Administrator then so is the UAC.

If the AAM is turned off you will never be prompted for permission to run a program with Administrator Privileges. If it's turned on you will be prompted every time you try and run a program with Admin privileges.

So, right-click on a program and select "Run As Administrator" and see if it prompts you. If it does, then AAM is turned on. If AAM is turned on, and the Administrators Group auto ran every program with Admin privileges it would prompt you every single time you ran a program. If, however, the AAM is turned on but Administrator Group users ran only with the least required privileges then the prompt would only happen with those programs that specifically requested elevated privileges or those that the UAC recognizes as needing such privileges.

This is the difference. The Built-in Administrator, needs to be manually turned on and by default turns the UAC off preventing these prompts. The Administrators Group does not turn off the UAC and therefore the prompts continue but only when the program needs to run with Admin privileges. Which few do.

[photodrawken]

Yes, you're right about implied but not specific statements there. I'll keep searching MS for something more definitive....
It's just that whenever and wherever I choose "Run as administrator", I enter the username and password for a "normal" administrator account (not the username and password of The Infamous Hidden Administrator Account (TIHAA)). And the programs (or command prompt) run with enhanced privileges.

For example, the documentation for the System File Check tool:
http://support.microsoft.com/kb/929833#method1
contains this

1.Open an elevated command prompt. To do this, click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator. If you are prompted for an administrator password or for a confirmation, type the password, or click Allow.

It needs an administrator password, not the TIHAA one.

[LeviFiction]

Okay, I see where our miscommunication is.

My original post said that Administrator accounts do not run programs with admin privileges. What I meant was that it doesn't auto-run programs with admin privileges, not that it can't run with these privileges. The UAC in Windows only runs programs with the level of privileges it actually needs. PSP does not need Admin privileges so even if your account is an admin, not THE admin, it will not run with admin privileges until you tell it to do so.

Admin accounts are fully capable of doing most of the things that the hidden Administrator account can do. They can run programs with admin privileges. They can grant admin privileges to certain things. They do not, however, do this automatically. You still have to select "Run as Administrator" to activate those privileges.

That was my only point. If the plugin needed admin privileges, which we now know it doesn't, PSP was not being run with Administrator privileges even though the person running it was an Administrator. My point was he had to specifically tell it to run as administrator to gain those privileges.

So, you're right. They can run programs with admin privileges, but the permission must be explicitly given for each instance.

The exception to this rule is THE Administrator account, or turning off the UAC.

[photodrawken]

They do not, however, do this automatically. You still have to select "Run as Administrator" to activate those privileges.

Yes, you're right. I tested this by running a system utility under an administrator account and was prompted for a confirmation when making a change to the system.

So, I learned something today. It still appears that when running under an administrator's account a program will run with enhanced privileges and trigger a UAC prompt at times unless it's first started with "Run as administrator". What's still confusing is which activities will trigger the prompt and which activities will simply be allowed when "Run as administrator" is not used. For example, running Adobe's CS trials here under a standard user account will fail unless the programs are started with "Run as administrator", but under an administrator account will launch just fine without "Run as administrator"....

[LeviFiction]

From what I understand, and someone might correct me on this. The Admin group includes more than just admin privilege abilities.

So, admin users have more liberties than a standard user. There are things that don't require admin specific privileges but require privileges that standard users don't have. And if the program doesn't know to ask for these privileges it'll just fail under a standard user. So when you run as Administrator you gain all of those extra liberties for that instance of the program. Unfortunately, since we don't know what the program is doing to require it we'll never know for sure when a program is just failing and when it's failing due to privileges issues. Just have to try running as Administrator when a program fails.

[photodrawken]

Yep, it seems that for troubleshooting one can first run logged in to an administrator account and then if the failure still occurs also use "Run as administrator", but that's an imprecise method of tracking down a problem, for sure....