CreateProcess and error 740 (requires elevation)
in [Win32 Kernel]
|
From: Paul Baker [MVP, Windows Desktop Experience] on 18 Jan 2010 08:49 I find there to be too much blame in the software industry. I do not believe that Microsoft is out to break anything, in fact I believe they have had a pretty good track record of innovating without breaking stuff. Windows is also full of compatibility shims and old compatibility hard-code to "unbreak" a popular application for which either there are too many unpatched installations out there or the vendor was unwilling to fix it. I have seen some special behaviour targetted at "unbreaking" only Microsoft applications, but I have seen much more special behaviour targetted at "unbreaking" badly behaved independant applications as well. RealMedia should have debugged like Real programmers before taking legal action. This is incompetence on *RealMedia's* part. Too many times I have seen support articles on Microsoft's and an ISV's web site that mirror one another, essentially blaming the other for the incompatibility and passing the book. Come on, we can do better than that! Don't fall into the same trap! Usually there are factors on both sides, and both sides need to contemplate the best possible solution. It may come from one or both. It may be a software change or merely a documentation change. There will always be incompatibilities between software, especially if writte by different vendors. It's inevitable. I am not denying that your developers are top notch people, but even the most expert of them is not a mind reader, cannot glean much more than the documentation says and is not able to predict the future. All we can do is try our best to follow best practices and write defensive code and the incompatibilities should be rare. If you choose not to support and debug these incidents, that is certainly an understandable choice. Believe me, I totally understand from a business perspective. It could very well be a significant amount of resources you have to throw at it, or it could not. It may make sense if you can deal with a relatively low number of affected customers. But understand also that the cause is unknown and you may never find the real cause, besides "Microsoft sucks", if you do not look. Taking it to court is a cop out and it will not stand up without evidence that it lies entirely on Microsoft's side *and* that it is deliberate. You will need to debug to get the former information anyway. It would actually be way more resources that way. I hope, for your sake, that you said that only out of frustration. Paul "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: m on 19 Jan 2010 19:33 Well, industry consensus would be that VC 6 is obsolete. You may have misunderstood my point, but that isn't necessarily a good reason not to use it. Consider for a moment what you are saying. You have told us that your software, by virtue of its age and the number of dollars / man-hours invested, is perfect and so any failure must be the fault of Microsoft. This statement is clearly an overstatement of the synthesis of your remarks, but, notwithstanding any facetiousness, is accurate (not precise). You have told us all about what MS has done to break your code, but not about what you have had to do, or might have to do, to fix it. This indicates, at least to us, that you don't know what you might have to do to fix it, and are simply raising hue and cry. From a probabilistic point of view, the occurrence of a single issue of a nature, greatly increases the likelihood of discovering another because it means that the program, either by virtue of its nature, or its environment, or the means thru which it was constructed, is susceptible to such issues. This is not programming, nor technical in any way, but simple logic. Also, to win a lawsuit in the USA you would need to prove either: 1) malice on the part of Microsoft; or 2) anti-trust. In the fist case, you would need documentary evidence that Microsoft, or its agents, deliberately sought to undermine your commercial venture by breaking compatibility with legacy versions of your application - very hard And in the second case, you would need to demonstrate at least that the public interest is damaged by not including support for legacy versions of your application in newer operating systems - nearly impossible. because the obvious counter argument, supported by your own sentiments, is that the product, in its existing published form, was designed for a specific platform and not for an arbitrary future operating system. And hence one should expect it not to work, but if it does then it is a bonus. Remember that Truth and Justice do not reign in earth, and content yourself with the consequences. "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ukRaql#lKHA.3128(a)TK2MSFTNGP02.phx.gbl... > 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: Hector Santos on 19 Jan 2010 22:33 m wrote: > Consider for a moment what you are saying. You have told us that your > software, by virtue of its age and the number of dollars / man-hours > invested, is perfect and so any failure must be the fault of Microsoft. No, that was not stated and people who known me over the years here know that is FAR from what was stated. You should understand the points before commenting. -- HLS
From: Hector Santos on 20 Jan 2010 01:15 Hector Santos wrote: > m wrote: > >> Consider for a moment what you are saying. You have told us that your >> software, by virtue of its age and the number of dollars / man-hours >> invested, is perfect and so any failure must be the fault of Microsoft. > > > No, that was not stated and people who known me over the years here know > that is FAR from what was stated. You should understand the points > before commenting. If it will help, the question of FAULT is not the issue. MS made a decision. I question that decision or better said, how it was approached. Your angle, which I really don't wish to give much attention to, is based on that if a decision is made it is MORE often based on the premise that most, if not all, effected software was incorrectly written in the first place. That many-years of software engineering where when uncertainty is a TABOO and not part of the equation is a fallacy and doesn't apply. That people here are really not that intelligent and you (generally speaking) know better than them. That 14 years of commercial Win32 products design and development means nothing. I'm not going to fall into this rhetorical judo position that is akin to the proverbial no-win question of "When was the last time you beat your wife?" In short, I will say that the argument falls flat when in fact, a system was well designed following software practices (which you probably can't define without argument) and yet a change is required not on a technical basis, but a subject policy decision. Veterans of the Microsoft development market knows exactly what is being pointed out. Believe it or not, the comments is about hope - that Microsoft, as they evolved and that evolution increasingly includes a greater need to break Win32 compatibility, that it is done with a greater regard and approach that does not put or minimizes the burden on vendors. I am speaking of integrity and software engineering ethics. As other as pointed out and it was well understood, MS does not attempt to break software and has historically done things to circumvent issues. I'm concern that this mentality is increasingly being disregarded. It might be due to the new project engineers and management. I personally began to concern when Ray Ozzie came on board which in summary, his very nature will naturally create more contention issues in the area of MS OS vs MS APPLICATION integration, in addition, the increasing advantage the using "scare of security" as a means to promote change with less liability when in years past, and still today when push comes to shove, it as a both a illegal and technical practice (See UCITA, Article 2B). Before responding, research and study the points. -- HLS
From: Jonathan de Boyne Pollard on 19 Jan 2010 23:11
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <blockquote cite="mid:ukJABhWmKHA.4808(a)TK2MSFTNGP04.phx.gbl" type="cite"> <p>In the fist case, you would need documentary evidence that Microsoft, or its agents, deliberately sought to undermine your commercial venture by breaking compatibility with legacy versions of your application - very hard </p> </blockquote> <p>Here's some irony: This (sub-)thread began with M. Santos railing against installer detection and elevation, which is a feature that exists in order to <em>provide</em> compatibility with existing installation programs, and to <em>stop</em> them from breaking.<br> </p> <p><a href="http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/legacy-is-not-a-pejorative.html">"Legacy" is not a pejorative</a>, by the way. M. Santos has not died and left things in xyr will.<br> </p> </body> </html> |