When logged in as administrator with UAC enabled I cannot run any executable that requires elevation. The processes start, do a few mundane looking things (Query Security, Query Name Information, Query Standard Information) and then exit suddenly with STATUS_ELEVATION_REQUIRED. Comparing procmon logs with successfully running the program shows that the sudden exit is the only difference. A dialog is displayed on the screen that says invalid parameter. The UAC dialog is never presented.
A very similar problem seems to have been discussed in the context of a file system driver which is returning a file system type other than one windows in familiar with (i.e. NTFS, FAT, etc) in the IRP_MJ_QUERY_VOLUME_INFORMATION FileFsAttributeInformation but has never been resolved. In my case I am filtering all NTFS volumes and that file system type is correctly being returned when asked.
One of the other discussions:
http://www.osronline.com/showThread.cfm?link=129811
http://www.osronline.com/showThread.cfm?link=129879
The other:
http://www.osronline.com/showThread.cfm?link=121274
I have disabled the main functionality in our driver (redirecting IO requests from volume to volume) and the problem persists. Removing the driver stops the behavior. This driver is well tested under XP and passes all our unit tests in Vista.
Anyone have any suggestions? I’m basically out of things to look at.
Are you doing anything in the MJ_SET_SECURITY space? If so look out for
LABEL_SECURITY_INFORMATION…
wrote in message news:xxxxx@ntfsd…
> When logged in as administrator with UAC enabled I cannot run any
> executable that requires elevation. The processes start, do a few mundane
> looking things (Query Security, Query Name Information, Query Standard
> Information) and then exit suddenly with STATUS_ELEVATION_REQUIRED.
> Comparing procmon logs with successfully running the program shows that
> the sudden exit is the only difference. A dialog is displayed on the
> screen that says invalid parameter. The UAC dialog is never presented.
>
> A very similar problem seems to have been discussed in the context of a
> file system driver which is returning a file system type other than one
> windows in familiar with (i.e. NTFS, FAT, etc) in the
> IRP_MJ_QUERY_VOLUME_INFORMATION FileFsAttributeInformation but has never
> been resolved. In my case I am filtering all NTFS volumes and that file
> system type is correctly being returned when asked.
>
> One of the other discussions:
> http://www.osronline.com/showThread.cfm?link=129811
> http://www.osronline.com/showThread.cfm?link=129879
>
> The other:
> http://www.osronline.com/showThread.cfm?link=121274
>
> I have disabled the main functionality in our driver (redirecting IO
> requests from volume to volume) and the problem persists. Removing the
> driver stops the behavior. This driver is well tested under XP and passes
> all our unit tests in Vista.
>
> Anyone have any suggestions? I’m basically out of things to look at.
>
We’re not registered for MJ_SET_SECURITY callbacks.
I’ve gotten another procmon trace of a different machine with UAC on where I deny my test program its elevation when the dialog pops up. Whats interesting is the process exits much much sooner in this test scenario when compared to my problem scenario where UAC is enabled and our driver is running. In my case its almost as if the system doesn’t realize it needs to prompt to elevate. Normally, if you deny the elevation prompt, the process in question exits almost immediately upon starting.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Wednesday, September 23, 2009 11:42 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Vista UAC trouble with minifilter
Are you doing anything in the MJ_SET_SECURITY space? If so look out for
LABEL_SECURITY_INFORMATION…
wrote in message news:xxxxx@ntfsd…
> When logged in as administrator with UAC enabled I cannot run any
> executable that requires elevation. The processes start, do a few mundane
> looking things (Query Security, Query Name Information, Query Standard
> Information) and then exit suddenly with STATUS_ELEVATION_REQUIRED.
> Comparing procmon logs with successfully running the program shows that
> the sudden exit is the only difference. A dialog is displayed on the
> screen that says invalid parameter. The UAC dialog is never presented.
>
> A very similar problem seems to have been discussed in the context of a
> file system driver which is returning a file system type other than one
> windows in familiar with (i.e. NTFS, FAT, etc) in the
> IRP_MJ_QUERY_VOLUME_INFORMATION FileFsAttributeInformation but has never
> been resolved. In my case I am filtering all NTFS volumes and that file
> system type is correctly being returned when asked.
>
> One of the other discussions:
> http://www.osronline.com/showThread.cfm?link=129811
> http://www.osronline.com/showThread.cfm?link=129879
>
> The other:
> http://www.osronline.com/showThread.cfm?link=121274
>
> I have disabled the main functionality in our driver (redirecting IO
> requests from volume to volume) and the problem persists. Removing the
> driver stops the behavior. This driver is well tested under XP and passes
> all our unit tests in Vista.
>
> Anyone have any suggestions? I’m basically out of things to look at.
>
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.111/2386 - Release Date: 09/23/09 05:52:00
I narrowed it down to our handling of IRP_MJ_QUERY_VOLUME_INFORMATION FileFsAttributeInformation. Even though the structure was filled out correctly, we returned just sizeof( FILE_FS_ATTRIBUTE_INFORMATION) in IoStatus.information not including the bytes used for the variable length string for the file system type at the end of that structure.
I guess XP is very forgiving and doesn’t care about this kind of mistake. Vista on the other hand must lose its head and decide it won’t/can’t elevate to run things off that volume. That’s why my test program seemed to get pretty far and then just hit a wall and exit the sudden way it did.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Matthew Norgren
Sent: Wednesday, September 23, 2009 12:42 PM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] Vista UAC trouble with minifilter
We’re not registered for MJ_SET_SECURITY callbacks.
I’ve gotten another procmon trace of a different machine with UAC on where I deny my test program its elevation when the dialog pops up. Whats interesting is the process exits much much sooner in this test scenario when compared to my problem scenario where UAC is enabled and our driver is running. In my case its almost as if the system doesn’t realize it needs to prompt to elevate. Normally, if you deny the elevation prompt, the process in question exits almost immediately upon starting.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Wednesday, September 23, 2009 11:42 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Vista UAC trouble with minifilter
Are you doing anything in the MJ_SET_SECURITY space? If so look out for
LABEL_SECURITY_INFORMATION…
wrote in message news:xxxxx@ntfsd…
> When logged in as administrator with UAC enabled I cannot run any
> executable that requires elevation. The processes start, do a few mundane
> looking things (Query Security, Query Name Information, Query Standard
> Information) and then exit suddenly with STATUS_ELEVATION_REQUIRED.
> Comparing procmon logs with successfully running the program shows that
> the sudden exit is the only difference. A dialog is displayed on the
> screen that says invalid parameter. The UAC dialog is never presented.
>
> A very similar problem seems to have been discussed in the context of a
> file system driver which is returning a file system type other than one
> windows in familiar with (i.e. NTFS, FAT, etc) in the
> IRP_MJ_QUERY_VOLUME_INFORMATION FileFsAttributeInformation but has never
> been resolved. In my case I am filtering all NTFS volumes and that file
> system type is correctly being returned when asked.
>
> One of the other discussions:
> http://www.osronline.com/showThread.cfm?link=129811
> http://www.osronline.com/showThread.cfm?link=129879
>
> The other:
> http://www.osronline.com/showThread.cfm?link=121274
>
> I have disabled the main functionality in our driver (redirecting IO
> requests from volume to volume) and the problem persists. Removing the
> driver stops the behavior. This driver is well tested under XP and passes
> all our unit tests in Vista.
>
> Anyone have any suggestions? I’m basically out of things to look at.
>
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.111/2386 - Release Date: 09/23/09 05:52:00
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.111/2386 - Release Date: 09/23/09 05:52:00