PAGE_FAULT_IN_NONPAGED_AREA blue screen

I am using Windows Vista Business SP1 to run an application that is running
fine on Windows XP. On Vista, it crashes and gives a blue screen with the
'PAGE_FAULT_IN_NONPAGED_AREA' error. This problem only happens if my program
runs from the 'Program files' folder. I would really like to keep it in the
'Program files' folder, so how can I avoid the crash?
Thank you for your help

This error indicates a 'failure of installed hardware' and is probably the
problem that occurs when a hardware drive is not compatible, or in an
inaccessible folder. Since it runs outside the Programs folder (the "Program
Files" folder is virtual in Vista, and is only a forwarding address) I would
try to identify the driver, and move it into the System32 folder. The Event
Viewer should list your error and include the name of the driver file
needed.

--
Please use the Communities guidelines when posting.
http://www.microsoft.com/wn3/locales...help_en-us.htm
Use the "Ratings" feature. It helps the new users.
Mark L. Ferguson MS-MVP
https://mvp.support.microsoft.com/profile/Mark.Ferguson

"Maryta" <> wrote in message
news:456C412A-B2D6-499A-941F-...
> I am using Windows Vista Business SP1 to run an application that is
> running
> fine on Windows XP. On Vista, it crashes and gives a blue screen with the
> 'PAGE_FAULT_IN_NONPAGED_AREA' error. This problem only happens if my
> program
> runs from the 'Program files' folder. I would really like to keep it in
> the
> 'Program files' folder, so how can I avoid the crash?
> Thank you for your help

Thank you Mark.
The problem seems to be related to a National instruments driver, located in
c:\Program files\NI, etc., and I cannot move it.

If this folder is so special in Vista, would there be a security option that
could be turn off, just for this driver?
Thanks

Hi,

No such option. The driver file is trying to write to the \Program Files
directory during operation, something that is not allowed in a user's normal
runtime. It needs to run virtualized in Vista under the user appdata, but
apparently isn't. There are two potential solutions: 1) The software vendor
updates or patches the program to run properly under Vista. 2) Right click
the .exe or shortcut when you want to run it and choose 'run as
adminstrator', this will give it sufficient privilege to write to the
folder.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP
http://mvp.support.microsoft.com/
Windows help - www.rickrogers.org
My thoughts http://rick-mvp.blogspot.com

"Maryta" <> wrote in message
news:F51598B0-E422-4616-A75E-...
>
> Thank you Mark.
> The problem seems to be related to a National instruments driver, located
> in
> c:\Program files\NI, etc., and I cannot move it.
>
> If this folder is so special in Vista, would there be a security option
> that
> could be turn off, just for this driver?
> Thanks

Mark L. Ferguson <> wrote:
>
> Since it runs outside the Programs folder (the
> "Program Files" folder is virtual in Vista, and is only a forwarding
> address)

The Program Files folder is not a 'virtual folder' in Vista, as it
physically exists in the filesystem. You are confusing the fact that
Program Files is virtualised, with virtual folders, like Saved Searches, or
the Recycle Bin.

ss.

Rick Rogers <> wrote:
>
> No such option. The driver file is trying to write to the \Program Files
> directory during operation, something that is not allowed in a user's
> normal runtime. It needs to run virtualized in Vista under the user
> appdata, but apparently isn't. There are two potential solutions: 1)
> The software vendor updates or patches the program to run properly
> under Vista. 2) Right click the .exe or shortcut when you want to run
> it and choose 'run as adminstrator', this will give it sufficient
> privilege to write to the folder.
>

It would be easier to install it in a non-UAC-protected alternative location
for legacy apps. I thought that Vista does this automatically, normally?

ss.

Hi,

It still installs to the default directory, but virtualization generally
loads to the user environment. The problems arise when a file routine is
hard-coded to the \Program Files rather than using a variable.

--
Best of Luck,

Rick Rogers, aka "Nutcase" - Microsoft MVP
http://mvp.support.microsoft.com/
Windows help - www.rickrogers.org
My thoughts http://rick-mvp.blogspot.com

"Synapse Syndrome" <> wrote in message
news:%...
> Rick Rogers <> wrote:
>>
>> No such option. The driver file is trying to write to the \Program Files
>> directory during operation, something that is not allowed in a user's
>> normal runtime. It needs to run virtualized in Vista under the user
>> appdata, but apparently isn't. There are two potential solutions: 1)
>> The software vendor updates or patches the program to run properly
>> under Vista. 2) Right click the .exe or shortcut when you want to run
>> it and choose 'run as adminstrator', this will give it sufficient
>> privilege to write to the folder.
>>
>
> It would be easier to install it in a non-UAC-protected alternative
> location for legacy apps. I thought that Vista does this automatically,
> normally?
>
> ss.
>
>
>
>

Rick Rogers <> wrote:

<top-posting macro corrected>

>>> No such option. The driver file is trying to write to the \Program
>>> Files directory during operation, something that is not allowed in
>>> a user's normal runtime. It needs to run virtualized in Vista under
>>> the user appdata, but apparently isn't. There are two potential
>>> solutions: 1) The software vendor updates or patches the program to
>>> run properly under Vista. 2) Right click the .exe or shortcut when
>>> you want to run it and choose 'run as adminstrator', this will give
>>> it sufficient privilege to write to the folder.
>>>
>>
>> It would be easier to install it in a non-UAC-protected alternative
>> location for legacy apps. I thought that Vista does this automatically,
>> normally?
>>
>
> Hi,
>
> It still installs to the default directory, but virtualization generally
> loads to the user environment. The problems arise when a file routine is
> hard-coded to the \Program Files rather than using a variable.

I seem to remember Vista installing certain legacy apps in another location,
when they wrote to Program Files.

ss.