CreateProcess and error 740 (requires elevation)
in [Win32 Kernel]
|
From: Hector Santos on 16 Jan 2010 20:04 Alexander Grigoriev wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:uYeN8TmlKHA.3128(a)TK2MSFTNGP02.phx.gbl... >> In fact, we put out a notice for ALL our customers to begin calling >> MICROSOFT for any issue they see related to OS updates. We are not going >> to swallow the cost on this and if this continues I am seriously >> contemplating contacting the FCC for antitrust violations. This is not a >> laughing matter. While no one here needs to know any of this, MS >> increasing behavior of breaking well established applications in the name >> of solving their own security problems problems and possibly using the >> opportunity to break WIN32 compatibility to force customers to upgrade is >> unacceptable. >> >> -- >> HLS > > Microsoft goes to great lengths to avoid breaking application, even buggy > ones. But it can't do that for all buggy apps. Programmers make all kinds of > wrong assumptions, that only hold true in the particular OS version. And > sometimes they have to break compatibility because of security concerns. I > suspect your RPC issue is because of that. > > I remember CEO of RealMedia testified at antitrust hearing that MS > intentionally broke their software. In the end it was found that the issue > was in the app in question. Go figure. I agree. However, and I am speaking only with the hope that it may trickle some synergism with perhaps a MS lurker and in some Quality Circle meeting he/she says: "You know, we need to do a better job here. We should not break the Good will of our long time ISV and customer base. Our Win32 RPC client/server application has been in the market since 1996. Highly engineered by top notch system engineers, and must say pragmatic and conservative bunch who will do nothing that is questionable or not well understood. This is not open source people with poor coding habits based on the theory "others" will fix problems. In addition, we have millions of hours of field operations across all market segments and WIN32 operating systems. Installed on over hundreds of thousands of in every market segment, thousands of which are 24x7x265 critical mission operations, many of which had Microsoft themselves test it to resolve issues, like in one case last year with a EICON/DIVA virtual comm port driver found as the source creating intermittent blue screens. Our input to was provide technical operation information, a free enterprise copy and the WIN32 com properties and timeout settings used. Microsoft found that problem on behalf of this major corporation and that is just one case I happen to remember. Microsoft is very aware of our software - or was. But consider the dilemma: 14+ years of successful RPC server operations on all versions of WIN32, finely tuned, no stupid assumptions, suddenly breaking with new OS patches, then as the CTO and chief engineer, that begins to worry you - anyone or should. Outside of application specific changes, fixes, enhancement over the years, nothing at the OS WIN32 level was at issue BY design again because we want no surprises. We don't use anything that is "new per se" or specific to one OS. This is not .NET. It is still VS 6.0 compiled code - again, on purpose. .NET dependency has too much overhead, variant OS dependency and .NET is still a moving target. We do have a .NET rebuilt version for over a year now - no need to introduce it. Why cause more support issues when you don't have to when the demand was not there for it. We only had to make one change to the RPC server in its 14 years related to the 2005/2006? DCOM fix MS made that restricted remote (LAN) RPC clients. We don't use DCOM for server discovery, our proprietary protocol predated DCOM, yet we still had to make a server change to get around the new restriction to resolve a buffer overrun issue in their DCOM protocol that had nothing to do with us. I seriously doubt there is any "buggy" code or "wrong assumptions" here at the RPC level, If you want to suggest a CHANGE in OS Win32 RPC interface consideration like there was for DCOM caused fix we had to make, that would be different, but then again that is the sort of the material for anti-trust. The issue is the "behavior" that is increasingly becoming one, not technical, but strategic with an increasingly obvious lower regard to breaking existing, trusted and *installed* (again, INSTALLED) applications in the presumed name of security in their belief the industry mindset has changed enough over the years that this once unacceptable practice would be acceptable today. It is not, but unfortunately, the "scare of security threats" has been molded in a way that it now sounds it is NOT OS related at all but rather a natural phenomenon of life. Case in point? Your response and the acceptance that its FINALLY OK to break software in the name of security even when the software MAY not be related to the problem the OS fix attempts to resolve. There is one fortunate good thing here. So far it one report. We have to pay more attention here in coming weeks/months to come. One thing about our system is that you only hear from customers when something happens. But we never known if an IT admin found a problem by updating the OS and really don't have a choice by to revert because of the critical operation need. They can't afford any down time. They know MS screwed up their critical operation that was working perfectly fine before a OS patch. So its many times its an easy choice for them. Many times the IT admin knows NOTHING about our software other than that it MUST be running on the box. We would love to get reports, but that is not always the case. We did get one this week. So we will have to see in weeks and months to come. Finally, I understand the MS pressures here. But there is a compromise. Microsoft SHOULD definitely consider to include within the OS patching for security related issues, a AUTOMATIC White list for INSTALLED applications. That is a far better solution than to blindly *break* installed and trusted applications. -- HLS
From: m on 17 Jan 2010 20:45 Should that automatic white list also include the malware that the user has had installed but hadn't noticed yet? This kind of thing is never as black and white as it might seem. As a side note, the fact that you have already needed to patch your code because of a change to an 'unrelated' component shipped by Microsoft, should reduce your confidence in your code. It sounds like you have isolated the problem to a specific hotfix, but I suggest that rather then ranting, you first find out what the problem actually is (on a binary level) and then repost so we can better assess whether you have a case. IMHO, the use of the 'net' .NET framework, or the obsolete VC6 compiler has no bearing on whether good engineering practices have been employed. All it indicates, combined with the complaint about Windows 7 behaviour months after retail release, is that you have chosen a specific technology platform and are not interested in changing. This is neither good nor bad, but does have consequences. "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u$7vcExlKHA.1648(a)TK2MSFTNGP05.phx.gbl... > Alexander Grigoriev wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >> news:uYeN8TmlKHA.3128(a)TK2MSFTNGP02.phx.gbl... >>> In fact, we put out a notice for ALL our customers to begin calling >>> MICROSOFT for any issue they see related to OS updates. We are not going >>> to swallow the cost on this and if this continues I am seriously >>> contemplating contacting the FCC for antitrust violations. This is not >>> a laughing matter. While no one here needs to know any of this, MS >>> increasing behavior of breaking well established applications in the >>> name of solving their own security problems problems and possibly using >>> the opportunity to break WIN32 compatibility to force customers to >>> upgrade is unacceptable. >>> >>> -- >>> HLS >> >> Microsoft goes to great lengths to avoid breaking application, even buggy >> ones. But it can't do that for all buggy apps. Programmers make all kinds >> of wrong assumptions, that only hold true in the particular OS version. >> And sometimes they have to break compatibility because of security >> concerns. I suspect your RPC issue is because of that. >> >> I remember CEO of RealMedia testified at antitrust hearing that MS >> intentionally broke their software. In the end it was found that the >> issue was in the app in question. Go figure. > > I agree. > > However, and I am speaking only with the hope that it may trickle some > synergism with perhaps a MS lurker and in some Quality Circle meeting > he/she says: > > "You know, we need to do a better job here. We should > not break the Good will of our long time ISV and > customer base. > > Our Win32 RPC client/server application has been in the market since 1996. > Highly engineered by top notch system engineers, and must say pragmatic > and conservative bunch who will do nothing that is questionable or not > well understood. This is not open source people with poor coding habits > based on the theory "others" will fix problems. > > In addition, we have millions of hours of field operations across all > market segments and WIN32 operating systems. Installed on over hundreds of > thousands of in every market segment, thousands of which are 24x7x265 > critical mission operations, many of which had Microsoft themselves test > it to resolve issues, like in one case last year with a EICON/DIVA virtual > comm port driver found as the source creating intermittent blue screens. > Our input to was provide technical operation information, a free > enterprise copy and the WIN32 com properties and timeout settings used. > Microsoft found that problem on behalf of this major corporation and that > is just one case I happen to remember. Microsoft is very aware of our > software - or was. > > But consider the dilemma: > > 14+ years of successful RPC server operations on all versions of WIN32, > finely tuned, no stupid assumptions, suddenly breaking with new OS > patches, then as the CTO and chief engineer, that begins to worry you - > anyone or should. > > Outside of application specific changes, fixes, enhancement over the > years, nothing at the OS WIN32 level was at issue BY design again because > we want no surprises. We don't use anything that is "new per se" or > specific to one OS. This is not .NET. It is still VS 6.0 compiled code - > again, on purpose. .NET dependency has too much overhead, variant OS > dependency and .NET is still a moving target. We do have a .NET rebuilt > version for over a year now - no need to introduce it. Why cause more > support issues when you don't have to when the demand was not there for > it. > > We only had to make one change to the RPC server in its 14 years related > to the 2005/2006? DCOM fix MS made that restricted remote (LAN) RPC > clients. We don't use DCOM for server discovery, our proprietary protocol > predated DCOM, yet we still had to make a server change to get around the > new restriction to resolve a buffer overrun issue in their DCOM protocol > that had nothing to do with us. > > I seriously doubt there is any "buggy" code or "wrong assumptions" here at > the RPC level, If you want to suggest a CHANGE in OS Win32 RPC interface > consideration like there was for DCOM caused fix we had to make, that > would be different, but then again that is the sort of the material for > anti-trust. > > The issue is the "behavior" that is increasingly becoming one, not > technical, but strategic with an increasingly obvious lower regard to > breaking existing, trusted and *installed* (again, INSTALLED) applications > in the presumed name of security in their belief the industry mindset has > changed enough over the years that this once unacceptable practice would > be acceptable today. It is not, but unfortunately, the "scare of security > threats" has been molded in a way that it now sounds it is NOT OS related > at all but rather a natural phenomenon of life. Case in point? Your > response and the acceptance that its FINALLY OK to break software in the > name of security even when the software MAY not be related to the problem > the OS fix attempts to resolve. > > There is one fortunate good thing here. So far it one report. We have to > pay more attention here in coming weeks/months to come. One thing about > our system is that you only hear from customers when something happens. > But we never known if an IT admin found a problem by updating the OS and > really don't have a choice by to revert because of the critical operation > need. They can't afford any down time. They know MS screwed up their > critical operation that was working perfectly fine before a OS patch. So > its many times its an easy choice for them. Many times the IT admin knows > NOTHING about our software other than that it MUST be running on the box. > We would love to get reports, but that is not always the case. We did get > one this week. > > So we will have to see in weeks and months to come. > > Finally, I understand the MS pressures here. But there is a compromise. > Microsoft SHOULD definitely consider to include within the OS patching for > security related issues, a AUTOMATIC White list for INSTALLED > applications. That is a far better solution than to blindly *break* > installed and trusted applications. > > -- > HLS
From: Pavel A. on 17 Jan 2010 21:12 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u$7vcExlKHA.1648(a)TK2MSFTNGP05.phx.gbl... .............. > Our Win32 RPC client/server application has been in the market since 1996. > Highly engineered by top notch system engineers, and must say ............. > In addition, we have millions of hours of field operations across all > market segments and WIN32 operating systems. Installed on over hundreds of > thousands of in every market segment, thousands of which are 24x7x265 > critical mission operations, many of which had Microsoft themselves test > it to resolve issues, like in one case last year with ........ Ok, then you have a relatively high profile issue. The MS product support is exactly for this. Regards, --pa
From: Hector Santos on 17 Jan 2010 21:53 m wrote: > Should that automatic white list also include the malware that the user > has had installed but hadn't noticed yet? This kind of thing is never > as black and white as it might seem. Sure, but using pareto's principle, MOST systems would have more trust on what is already installed, especially in critical mission applications setups and operations. You can't presume that ALL MACHINE are prone to uncertainty and non-understanding by the administrators. The bottom line is that any excuse to blindly break working operations really doesn't hold. > As a side note, the fact that you have already needed to patch your code > because of a change to an 'unrelated' component shipped by Microsoft, > should reduce your confidence in your code. No it doesn't. Not at all. I think there would be more people than not to not think that way. Especially in systems that have years of development into it. Do not assume people are STUPID. > IMHO, the use of the 'net' .NET framework, or the obsolete VC6 compiler > has no bearing on whether good engineering practices have been > employed. So all those million dollars engineerings investment and years was a fallacy? It doesn't hold water. What is a fallacy is the presumption that declaring something obsolete and adding additional layers of overhead that in many areas is still a moving target and unsettled is better for you. The evidence shows the presumption is not very strong at all. The problem here is long time problem with the MS OS vs MS APPLICATION integration idea with Microsoft - a basic argument in Anti-trust and still open idea and need to possibly split the two organizations. A forgotten issue I must say, that MS seems to be taken advantage. Maybe a wake up is necessary with the new Administration. A MS application was broken and increasingly, MS uses the opportunity to use an OS fix as a way to address the problem and to strategically force upgrades by breaking existing applications. Thats the problem here. -- HLS
From: Pavel A. on 18 Jan 2010 07:59
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ukRaql#lKHA.3128(a)TK2MSFTNGP02.phx.gbl... ....... > Especially in systems that have years of development into it. Do not > assume people are STUPID. Couple of years ago, I worked in some Monsters Inc, and had to deal with a very embarrassing bug reported by a major customer. Until this happened, we believed that the product is stable. It has been installed in millions of computers, and tested by a great team, using all the state of the art methods. And still this happened, when a new 3rd party component slightly changed the timing. After few lessons like this, would never assume anything. > The problem here is long time problem with the MS OS vs MS APPLICATION > integration idea with Microsoft - a basic argument in Anti-trust and still > open idea and need to possibly split the two organizations. A forgotten > issue I must say, that MS seems to be taken advantage. Maybe a wake up is > necessary with the new Administration. A MS application was broken and > increasingly, MS uses the opportunity to use an OS fix as a way to address > the problem and to strategically force upgrades by breaking existing > applications. Thats the problem here. Re. the new Administration: they are planning their own upgrades to The System... Possibly, with similar effect on many our apllications... Regards, --pa |