Unable to run MFC app on Vista with UAC enabled
in [MFC]
|
From: Clayton on 9 May 2008 18:10 Application Description: The Application is a MFC C++ unmanaged code application, which utilizes Visual Studio .Net 2003 to compile and InstallShield Version 12 to deploy. The application is intended to be installed on the following Operating Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. Problem Description: On Windows Vista, once installed the application executes as expected one or two times then a failure occurs for every execution thereafter. The security feature UAC, User Access Control, is enabled before and after installation, and the installation is performed using an account with Administrator rights. Performing "Run as Administrator" on the right click menu does not resolve the problem and the same error occurs. The crash details are as follows: Problem signature: Problem Event Name: APPCRASH Application Name: ImageDeposit.exe Application Version: 4.3.0.3 Application Timestamp: 46d59493 Fault Module Name: Secur32.dll Fault Module Version: 6.0.6000.16386 Fault Module Timestamp: 4549bdd2 Exception Code: c0000005 Exception Offset: 000021f4 OS Version: 6.0.6000.2.0.0.768.3 Locale ID: 1033 Additional Information 1: 282b Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 Additional Information 3: 0afc Additional Information 4: 5f929daafffe194e86eb6223007ccac0 Current Work-Around: At this time, using a batch file that copies the executable, imagedeposit.exe, and executes that copy appears to be an effective means of running the application as expected. However, due to the somewhat technical means of implementing the work-around, a tech-support technician must make the necessary adjustments to each installation on Windows Vista.
From: Tom Serface on 10 May 2008 09:14 A c0000005 exception sounds like you may have a place in your code that is accessing memory beyond the end of an array or with an uninitialized pointer or something like that. Is there a chance that you have a string somewhere that has a chance of not being null terminate? Maybe this just happens to work on XP or Win2K because they are not as rigorous at protecting memory outside of the user's program. You would, of course, relax this kind of security by running as Admin or without UAC, but there may be a real bug that you're just missing. If you have an idea what the program is doing right before it stops you could put in log entries around that area to try to pin down where the problem is occurring. Tom "Clayton" <lcajones(a)yahoo.com> wrote in message news:OMj1xFisIHA.5580(a)TK2MSFTNGP04.phx.gbl... > > Application Description: > > The Application is a MFC C++ unmanaged code application, which utilizes > Visual Studio .Net 2003 to compile and InstallShield Version 12 to deploy. > > The application is intended to be installed on the following Operating > Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. > > Problem Description: > > On Windows Vista, once installed the application executes as expected one > or two times then a failure occurs for every execution thereafter. > The security feature UAC, User Access Control, is enabled before and after > installation, and the installation is performed using an account with > Administrator rights. > Performing "Run as Administrator" on the right click menu does not resolve > the problem and the same error occurs. > > The crash details are as follows: > > Problem signature: > Problem Event Name: APPCRASH > Application Name: ImageDeposit.exe > Application Version: 4.3.0.3 > Application Timestamp: 46d59493 > Fault Module Name: Secur32.dll > Fault Module Version: 6.0.6000.16386 > Fault Module Timestamp: 4549bdd2 > Exception Code: c0000005 > Exception Offset: 000021f4 > OS Version: 6.0.6000.2.0.0.768.3 > Locale ID: 1033 > Additional Information 1: 282b > Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 > Additional Information 3: 0afc > Additional Information 4: 5f929daafffe194e86eb6223007ccac0 > > > Current Work-Around: > At this time, using a batch file that copies the executable, > imagedeposit.exe, and executes that copy appears to be an effective means > of running the application as expected. > However, due to the somewhat technical means of implementing the > work-around, a tech-support technician must make the necessary adjustments > to each installation on Windows Vista. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
From: Joseph M. Newcomer on 10 May 2008 12:32 There is no concept of memory "outside the user's program" to be protected. The process defines the memory that is accessible, and therefore all of it is "inside" the user's program. One reason for failure could be an API that, without UAC, returns a valid value, but under UAC returns NULL, or one which returns BOOL which always returns TRUE without UAC but returns FALSE if UAC is enabled, but then doesn't modify memory in an appropriate fashion. For example TCHAR SillyFixedBuffer[SOME_SIZE]; SomeApi(SillyFixedBuffer); with UAC enabled, the character buffer is not initialized, so the subsequent _tcscpy(SomeOtherPlace, SillyFixedBuffer); is copying an unterminated buffer and clobbering everything in sight, whereas if the buffer had been filled in there would have been no buffer overrun. A good start would be to replace all the unsafe copies with either VS2005/2008 _tsccpy_s, or for older environments, using strsafe.h and doing StringCchCopy. Similarly for strcats. Looking for fixed buffers and failures to test APIs that might fail would be important also. Using App Verifier to test for memory overruns and such would not be a bad start. What is apalling about the crash diagnostic shown is that the most important piece of information, the program counter, is not displayed, nor is the register set. Vista really is a POS in terms of post-mortem analysis. If a "crash dump" is produced, it should be analyzed by the debugger to try to derive useful factoids like the register set (including program counter) and call stack. joe On Sat, 10 May 2008 06:14:51 -0700, "Tom Serface" <tom.nospam(a)camaswood.com> wrote: >A c0000005 exception sounds like you may have a place in your code that is >accessing memory beyond the end of an array or with an uninitialized pointer >or something like that. Is there a chance that you have a string somewhere >that has a chance of not being null terminate? Maybe this just happens to >work on XP or Win2K because they are not as rigorous at protecting memory >outside of the user's program. You would, of course, relax this kind of >security by running as Admin or without UAC, but there may be a real bug >that you're just missing. > >If you have an idea what the program is doing right before it stops you >could put in log entries around that area to try to pin down where the >problem is occurring. > >Tom > >"Clayton" <lcajones(a)yahoo.com> wrote in message >news:OMj1xFisIHA.5580(a)TK2MSFTNGP04.phx.gbl... >> >> Application Description: >> >> The Application is a MFC C++ unmanaged code application, which utilizes >> Visual Studio .Net 2003 to compile and InstallShield Version 12 to deploy. >> >> The application is intended to be installed on the following Operating >> Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. >> >> Problem Description: >> >> On Windows Vista, once installed the application executes as expected one >> or two times then a failure occurs for every execution thereafter. >> The security feature UAC, User Access Control, is enabled before and after >> installation, and the installation is performed using an account with >> Administrator rights. >> Performing "Run as Administrator" on the right click menu does not resolve >> the problem and the same error occurs. >> >> The crash details are as follows: >> >> Problem signature: >> Problem Event Name: APPCRASH >> Application Name: ImageDeposit.exe >> Application Version: 4.3.0.3 >> Application Timestamp: 46d59493 >> Fault Module Name: Secur32.dll >> Fault Module Version: 6.0.6000.16386 >> Fault Module Timestamp: 4549bdd2 >> Exception Code: c0000005 >> Exception Offset: 000021f4 >> OS Version: 6.0.6000.2.0.0.768.3 >> Locale ID: 1033 >> Additional Information 1: 282b >> Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 >> Additional Information 3: 0afc >> Additional Information 4: 5f929daafffe194e86eb6223007ccac0 >> >> >> Current Work-Around: >> At this time, using a batch file that copies the executable, >> imagedeposit.exe, and executes that copy appears to be an effective means >> of running the application as expected. >> However, due to the somewhat technical means of implementing the >> work-around, a tech-support technician must make the necessary adjustments >> to each installation on Windows Vista. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 10 May 2008 18:32 OK, maybe my comment was not technically correct according to some stricter axiom, but there *is* memory his pointers should not access and it is often the case that an initialized pointer or extended beyond the allocated space for an array can cause this sort of error. I've seen this in programs lots of times. I do believe the OS protects itself against some sorts of memory overwrites as well. I don't think it has anything to do with UAC, but it could be that UAC just makes it more prominent. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:l2jb24pr1qimd9v1e9mh0700iq8qs8r993(a)4ax.com... > There is no concept of memory "outside the user's program" to be > protected. The process > defines the memory that is accessible, and therefore all of it is "inside" > the user's > program. > > One reason for failure could be an API that, without UAC, returns a valid > value, but under > UAC returns NULL, or one which returns BOOL which always returns TRUE > without UAC but > returns FALSE if UAC is enabled, but then doesn't modify memory in an > appropriate fashion. > For example > > TCHAR SillyFixedBuffer[SOME_SIZE]; > SomeApi(SillyFixedBuffer); > > with UAC enabled, the character buffer is not initialized, so the > subsequent > > _tcscpy(SomeOtherPlace, SillyFixedBuffer); > > is copying an unterminated buffer and clobbering everything in sight, > whereas if the > buffer had been filled in there would have been no buffer overrun. > > A good start would be to replace all the unsafe copies with either > VS2005/2008 _tsccpy_s, > or for older environments, using strsafe.h and doing StringCchCopy. > Similarly for > strcats. Looking for fixed buffers and failures to test APIs that might > fail would be > important also. > > Using App Verifier to test for memory overruns and such would not be a bad > start. > > What is apalling about the crash diagnostic shown is that the most > important piece of > information, the program counter, is not displayed, nor is the register > set. Vista really > is a POS in terms of post-mortem analysis. If a "crash dump" is produced, > it should be > analyzed by the debugger to try to derive useful factoids like the > register set (including > program counter) and call stack. > joe > > On Sat, 10 May 2008 06:14:51 -0700, "Tom Serface" > <tom.nospam(a)camaswood.com> wrote: > >>A c0000005 exception sounds like you may have a place in your code that is >>accessing memory beyond the end of an array or with an uninitialized >>pointer >>or something like that. Is there a chance that you have a string >>somewhere >>that has a chance of not being null terminate? Maybe this just happens to >>work on XP or Win2K because they are not as rigorous at protecting memory >>outside of the user's program. You would, of course, relax this kind of >>security by running as Admin or without UAC, but there may be a real bug >>that you're just missing. >> >>If you have an idea what the program is doing right before it stops you >>could put in log entries around that area to try to pin down where the >>problem is occurring. >> >>Tom >> >>"Clayton" <lcajones(a)yahoo.com> wrote in message >>news:OMj1xFisIHA.5580(a)TK2MSFTNGP04.phx.gbl... >>> >>> Application Description: >>> >>> The Application is a MFC C++ unmanaged code application, which utilizes >>> Visual Studio .Net 2003 to compile and InstallShield Version 12 to >>> deploy. >>> >>> The application is intended to be installed on the following Operating >>> Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. >>> >>> Problem Description: >>> >>> On Windows Vista, once installed the application executes as expected >>> one >>> or two times then a failure occurs for every execution thereafter. >>> The security feature UAC, User Access Control, is enabled before and >>> after >>> installation, and the installation is performed using an account with >>> Administrator rights. >>> Performing "Run as Administrator" on the right click menu does not >>> resolve >>> the problem and the same error occurs. >>> >>> The crash details are as follows: >>> >>> Problem signature: >>> Problem Event Name: APPCRASH >>> Application Name: ImageDeposit.exe >>> Application Version: 4.3.0.3 >>> Application Timestamp: 46d59493 >>> Fault Module Name: Secur32.dll >>> Fault Module Version: 6.0.6000.16386 >>> Fault Module Timestamp: 4549bdd2 >>> Exception Code: c0000005 >>> Exception Offset: 000021f4 >>> OS Version: 6.0.6000.2.0.0.768.3 >>> Locale ID: 1033 >>> Additional Information 1: 282b >>> Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 >>> Additional Information 3: 0afc >>> Additional Information 4: 5f929daafffe194e86eb6223007ccac0 >>> >>> >>> Current Work-Around: >>> At this time, using a batch file that copies the executable, >>> imagedeposit.exe, and executes that copy appears to be an effective >>> means >>> of running the application as expected. >>> However, due to the somewhat technical means of implementing the >>> work-around, a tech-support technician must make the necessary >>> adjustments >>> to each installation on Windows Vista. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 11 May 2008 00:39 The OS always protects itself against any sort of memory overwrite because the OS is in a completely different part of the address space (nominally above location 0x80000000 unless you boot with the /3GB option), so it is never possible to write the OS memory. It doesn't exist in user space. There is ALWAYS memory that should not be written with values that are not sensible. The classic buffer overrun of a stack, which clobbers the return address, is a typical example. It might well be related to UAC, in that an API is supposed to set a pointer, or fill in a length, or something like that, but when UAC is enabled, this API fails. If the user has not checked to see that this API has failed, an illegal value (such as an illegal length) could be used to copy data, thus overwriting all kinds of random places in memory, causing massive malfunctions. So the correct thing to do is identify what is going on, determine what value went bad, see if that value depends upon the success of an API whose return value is not checked for success, and so on. joe On Sat, 10 May 2008 15:32:30 -0700, "Tom Serface" <tom.nospam(a)camaswood.com> wrote: >OK, maybe my comment was not technically correct according to some stricter >axiom, but there *is* memory his pointers should not access and it is often >the case that an initialized pointer or extended beyond the allocated space >for an array can cause this sort of error. I've seen this in programs lots >of times. I do believe the OS protects itself against some sorts of memory >overwrites as well. > >I don't think it has anything to do with UAC, but it could be that UAC just >makes it more prominent. > >Tom > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:l2jb24pr1qimd9v1e9mh0700iq8qs8r993(a)4ax.com... >> There is no concept of memory "outside the user's program" to be >> protected. The process >> defines the memory that is accessible, and therefore all of it is "inside" >> the user's >> program. >> >> One reason for failure could be an API that, without UAC, returns a valid >> value, but under >> UAC returns NULL, or one which returns BOOL which always returns TRUE >> without UAC but >> returns FALSE if UAC is enabled, but then doesn't modify memory in an >> appropriate fashion. >> For example >> >> TCHAR SillyFixedBuffer[SOME_SIZE]; >> SomeApi(SillyFixedBuffer); >> >> with UAC enabled, the character buffer is not initialized, so the >> subsequent >> >> _tcscpy(SomeOtherPlace, SillyFixedBuffer); >> >> is copying an unterminated buffer and clobbering everything in sight, >> whereas if the >> buffer had been filled in there would have been no buffer overrun. >> >> A good start would be to replace all the unsafe copies with either >> VS2005/2008 _tsccpy_s, >> or for older environments, using strsafe.h and doing StringCchCopy. >> Similarly for >> strcats. Looking for fixed buffers and failures to test APIs that might >> fail would be >> important also. >> >> Using App Verifier to test for memory overruns and such would not be a bad >> start. >> >> What is apalling about the crash diagnostic shown is that the most >> important piece of >> information, the program counter, is not displayed, nor is the register >> set. Vista really >> is a POS in terms of post-mortem analysis. If a "crash dump" is produced, >> it should be >> analyzed by the debugger to try to derive useful factoids like the >> register set (including >> program counter) and call stack. >> joe >> >> On Sat, 10 May 2008 06:14:51 -0700, "Tom Serface" >> <tom.nospam(a)camaswood.com> wrote: >> >>>A c0000005 exception sounds like you may have a place in your code that is >>>accessing memory beyond the end of an array or with an uninitialized >>>pointer >>>or something like that. Is there a chance that you have a string >>>somewhere >>>that has a chance of not being null terminate? Maybe this just happens to >>>work on XP or Win2K because they are not as rigorous at protecting memory >>>outside of the user's program. You would, of course, relax this kind of >>>security by running as Admin or without UAC, but there may be a real bug >>>that you're just missing. >>> >>>If you have an idea what the program is doing right before it stops you >>>could put in log entries around that area to try to pin down where the >>>problem is occurring. >>> >>>Tom >>> >>>"Clayton" <lcajones(a)yahoo.com> wrote in message >>>news:OMj1xFisIHA.5580(a)TK2MSFTNGP04.phx.gbl... >>>> >>>> Application Description: >>>> >>>> The Application is a MFC C++ unmanaged code application, which utilizes >>>> Visual Studio .Net 2003 to compile and InstallShield Version 12 to >>>> deploy. >>>> >>>> The application is intended to be installed on the following Operating >>>> Systems: Windows 2000 sp4; Windows XP sp2; and Windows Vista. >>>> >>>> Problem Description: >>>> >>>> On Windows Vista, once installed the application executes as expected >>>> one >>>> or two times then a failure occurs for every execution thereafter. >>>> The security feature UAC, User Access Control, is enabled before and >>>> after >>>> installation, and the installation is performed using an account with >>>> Administrator rights. >>>> Performing "Run as Administrator" on the right click menu does not >>>> resolve >>>> the problem and the same error occurs. >>>> >>>> The crash details are as follows: >>>> >>>> Problem signature: >>>> Problem Event Name: APPCRASH >>>> Application Name: ImageDeposit.exe >>>> Application Version: 4.3.0.3 >>>> Application Timestamp: 46d59493 >>>> Fault Module Name: Secur32.dll >>>> Fault Module Version: 6.0.6000.16386 >>>> Fault Module Timestamp: 4549bdd2 >>>> Exception Code: c0000005 >>>> Exception Offset: 000021f4 >>>> OS Version: 6.0.6000.2.0.0.768.3 >>>> Locale ID: 1033 >>>> Additional Information 1: 282b >>>> Additional Information 2: 96f82c9a65b406a6ce9e9400f8545391 >>>> Additional Information 3: 0afc >>>> Additional Information 4: 5f929daafffe194e86eb6223007ccac0 >>>> >>>> >>>> Current Work-Around: >>>> At this time, using a batch file that copies the executable, >>>> imagedeposit.exe, and executes that copy appears to be an effective >>>> means >>>> of running the application as expected. >>>> However, due to the somewhat technical means of implementing the >>>> work-around, a tech-support technician must make the necessary >>>> adjustments >>>> to each installation on Windows Vista. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
|
Pages: 1 Prev: MFC App unable to run in Vista with UAC enabled Next: CBitmap binary data |