Explaining 'The Binding Handle Is Invalid'

Published Wednesday, January 04, 2006 8:57 AM by greggm

source link: http://blogs.msdn.com/greggm/archive/2006/01/04/509243.aspx



Explaining 'The Binding Handle Is Invalid'

Today I want to try to give more insight into the 'Binding Handle Is Invalid' problem that a number of people have reported with the VS 2005 debugger.

First, if all you care about is how to solve the problem: Enable the 'Terminal Services' service and reboot. If you want to know more, read on.

The Terminal Services service

I have seen many users say something like "I don't want to enable the Terminal Services service because it’s a security risk". While I certainly understand this fear, this stems from a misunderstanding of what the Terminal Services service provides.

Enabling the Terminal Services service does NOT automatically enable Remote Desktop. If you want Remote Desktop disabled, then uncheck the remote desktop checkbox on the Remote tab of the properties dialog for My Computer. By default, Remote Desktop is disabled on Window XP, so unless you have gone and enabled it, it should already be disabled on your computer.

So, why is this service enabled by default? The Terminal Services service is enabled by default because in addition to the Remote Desktop functionality, it also provides for Remote Assistance, Fast User Switching, process listing, DCOM support, and probably lots of other stuff that I don't know about because I don't work on the TS team. If you are running with the Terminal Services service disabled, then you are running in a strange and not recommended configuration. You also have a broken Task Manager, and probably a bunch of other things that directly or indirectly rely on this service.

So please, regardless of what you want to do with Visual Studio, don't disable this service.

The Debugger

So why does the debugger rely on the Terminal Services service? The answer: Process listing. It turns out that the TS team provides the best task list API in Windows. Both tasklist.exe and taskmgr.exe use the TS service for this, and so it was natural for the debugger to follow their lead. Previous versions of Visual Studio got their task list through other task list APIs, but it turns out that this only works well if you run your code as LocalSystem. This was fine at the time because we had a service. However, for improved security and stability, the debugger got rid of their service for the 2005 release, so we needed to switch to the TS process listing API.

Why do you have such a lousy error message? Unfortunately, we didn't understand this problem until the very last days of the VS 2005 product cycle, and we didn't understand how many people run this way until after we shipped. At this point, it was too late to do anything about it. As the dev who wrote this code, I can only say that I am sorry that this has been such a hassle for you.

Are you guys going to fix this issue? We won't be able to completely fix the problem because the WTSEnumerateProcess API provides information that we can't get anywhere else. However, we can work around the problem in most of the common scenarios. I hope to see us ship this workaround in the next service pack. Furthermore, I expect to see us ship this work around in the next version of Visual Studio. However, I don't expect us to release this work around as a QFE because at this point at least, we don't think that this action would be in our customer's interest. QFEs are expensive to deploy for both Microsoft and our customers and generally, carry higher risk of potentially breaking other scenarios. The TS team has recommended that the Terminal Services service be enabled, so we believe that this is the right solution to address this issue.

What is affected? Any scenario where the debugger is told to attach to a process that is already running. This includes all ASP.NET scenarios, launching a C#/VB/J# project (unless the Visual Studio hosting process has been disabled), or manually trying to attach via the Attach To Processes dialog.



Related Links:

(good link)
http://kenno.wordpress.com/2006/06/25/the-binding-handle-is-invalid-error-in-visual-studio-2005/

http://grave.redirectme.net/devb/2006/04/22/the-binding-handle-is-invalid/

http://odalet.wordpress.com/2006/09/01/impossible-de-lancer-le-debugger-de-visual-studio-2005/

https://blogs.msdn.com/habibh/archive/2005/11/10/491572.aspx

EBooks Websites Free

Some Websites where you get lots of ebooks:

http://ebookslink.50g.com





http://www.freizeit.co.in

ftp://194.44.214.3/pub/e-books/

http://ebookslib.com

http://www.programmerworld.net/dotnet/books.htm

http://www.freebooksource.com/

www.programmingebooks.tk

www.free-itebooks.com

www.ebooks.com

www.intelligentedu.com/free_computer_books.html

www.click-now.net

www.developersbooks.com

www.techbooksforfree.com

www.freetechbooks.com

www.apress.com/free/index.html

www.itquestionbank.com

www.canonicalbooks.com/free-ebooks.shtml

www.diesel-ebooks.com/cgi-bin/category/COM051230/Programming-Software-Development.html

www.e-dsp.com/free-ebooks

http://e-library.net/Programming.htm

www.ebookmall.com

www.blogmarks.net/marks/tag/programming,ebooks

www.computer-books.us

http://cooldogebooks.blogspot.com

www.onlinecomputerbooks.com

www.ebooklobby.com/35/Programming

www.ebookexplorer.com/Computing/Programming.html

www.ebookslibrary.com/Computers_and_Internet_EBooks/Programming

www.goldenstarebooks.com/ebooks/2/programming-ebook.htm

www.digitalbookindex.com

www.csebooks.com

www.free-ebooks.net

www.freebookzone.com

www.ereader.com

www.ebooksportal.org

www.linux-tutorial.info

www.ebooks-download.com

www.info4java.com/free_ebooks

www.fictionwise.com/ebooks

www.techtoolblog.com/archives/195-free-online-programming-books

www.it-ebook.com/booklist.html

What's the difference between string and String?

In C# the type keywords actually are synonyms for the types. So int = System.Int32 short = System.Int16 and string = System.String.

They have the keywords because they are easier to remember and programmers coming from other languages like c/c++ would also be familiar with these types

Anyway, look at the C# keyword reference and you can find these things out. This was taken from the string keyword reference.

The string type represents a string of Unicode characters. string is an alias for String in the .NET Framework. Strings are immutable--the contents of a string object cannot be changed after the object is created.

Comparison of Live Hotmail, Gmail and Yahoo Mail

*This Article is taken from TechCrunch

The three applications, along with AOL mail, make up the vast majority of the 500 million or so webmail users around the world (see chart included in this post). Most of these users are still using the old, tedious, Ajax-free Yahoo Mail and Hotmail user interfaces, requiring page refreshes for every click. The new applications, along with Gmail, offer a much richer experience, much like Outlook or Mac mail. When these webmail clients are performing well, their speed and ease of use is easily as good as a desktop client.


Overall we prefer Gmail over all other webmail applications because performance (speed) is consistently fast, and emails can be tagged making search much more effective. They also offer more storage and other features, and it’s free. However, Yahoo and Live Hotmail offer more mainstream Outlook-like user interfaces (although Live Hotmail does not allow you to access other email accounts from their application), whereas Gmail takes some time to get used to. If you are looking for speed and tagging is important, Gmail is for you. If you are looking for the closest thing to Outlook online, go with Yahoo Mail.

Gmail
Gmail groups emails in a thread into a single line in the inbox. Some users love this, others hate it. It’s not my favorite feature, but I’ve gotten used to it. The best Gmail feature in my opinion is the ability to tag emails for better organization and search. None of the other services offer this. Gmail also has integrated Gtalk into the GMail interface, and continues to add other functionality as well (such as integration with Docs & Spreadsheets). Gmail is consistently fast, offers the most storage and free POP-in and POP-out, meaning you can use Gmail to access your other email accounts, or access GMail from whatever email client you use. It’s a near-perfect piece of software, and has only occasional hiccups. The fact that Google is paired with Google Calendar, the best online Calendar application, doesn’t hurt, either.

Windows Live Hotmail
The new Windows Live Hotmail will be a welcome change to Microsoft’s 228 million webmail users, but it falls short of the Yahoo and Gmail offerings. They offer 2 GB of storage, better than Yahoo, but there are no POP-in or POP-out features at all. If you want to access your account outside of the web site, you have to do it via Outlook or Outlook Express. It remains the slowest among the three in our tests.


Yahoo Mail
Yahoo Mail is very good, allowing users to access other email accounts (POP-in), but only offering POP-out access for an additional fee. This is probably due to the legacy users who are already paying for this feature - Yahoo may not want to give up this revenue stream. Storage is on the low side - only 1 GB, which is less than half of what Gmail offers. Still, Yahoo Mail has recently been running very fast and offers an intuitive, Outlook-like interface. Instant Messaging and RSS integration is awesome.

*This Article is taken from TechCrunch

Netscape 6: Updating Your JavaScript

by Andrew Starling

How much of your site's JavaScript do you need to change so it can be read by Netscape 6? Happily, only the complicated bits. Most simple JavaScript works in the new browser. But if you have scripts with separate lines for IE and NN, you'll need to update these. Here's a guide to recognising how much extra work the new browser has saddled you with.

Let's start with a round of applause for Netscape. Back in June I reviewed the first beta release of the new browser and gave it a resounding thumbs-down. Chances were, it seemed, the final release would suck louder than an aircraft toilet. But it doesn't. I eat my proverbial words. This is a decent browser and well worth a try, especially if you're currently using an old Netscape 4+ model.

It's not as fast as IE 5.5 and it's not going to topple the king from its throne, but it's good enough to secure a worthwhile slice of the market for Netscape. When combined with the Mozilla/Gecko final release, which should be out in a few months, that market share will be too large for any serious developer to ignore.

Most simple JavaScript works fine in N6. If, for example, you have links created in JavaScript or new windows that open and close, you should be OK. The main problem is if you get into the DOM (Document Object Model). The DOM for N6 isn't the same as for IE4+ or NN4. It's much closer to the W3C recommended DOM1 than either of these, but unfortunately that means the new browser won't accept a lot of DOM-related code already on the Net.

As a general rule, you're entering the realm of the DOM if you mess about with the properties of the Web page or the elements within it. If you don't change a property, you're probably not getting involved with the DOM.

Since the DOMs for IE and N4 were different even before N6 came along, most DOM-related code already recognises the browser (or, as some people say, parses the browser) and supplies separate lines of code for the main types.

If you're not very familiar with JavaScript, this is probably the easiest way to tell if your code will work in N6 unchanged or if it needs updating. Any scripts that devote their first few lines to recognising the browser will almost certainly need to be updated. In most cases they'll need a new section of code added that conforms with DOM1.

Changing the browser recognition element is relatively simple. Here's a detailed guide from WebReference.com and an alternative from Netscape.


The only problem is that after making these simple changes you will need to know what you're doing to rewrite code for DOM1. Note also that most DHTML code written by Dreamweaver and other DHTML authoring applications will need to be adjusted to work in N6.

Other Code


Discussion: Web Development Web Marketing Web Jobs Ecommerce Windows Weenie NT Weenie Linux Drivers HTML - Beginners Advanced HTML Wacky HTML Java JavaScript Web Audio Dynamic Sites CGI ASP ColdFusion MS FrontPage Bill Bashing
Check out and join our email-based Mailing Lists for Web developers.
Developer Channel
FlashKitJobs.webdeveloperJavaScript.comJavaScriptSourceJustSMILScriptSearchStreaming Media WorldWebDeveloper.comWebReferenceXMLFilesWDVL

Far Better Than Beta
Netscape 6: Updating Your JavaScript by Andrew Starling
How much of your site's JavaScript do you need to change so it can be read by Netscape 6? Happily, only the complicated bits. Most simple JavaScript works in the new browser. But if you have scripts with separate lines for IE and NN, you'll need to update these. Here's a guide to recognising how much extra work the new browser has saddled you with.December 6, 2000
Let's start with a round of applause for Netscape. Back in June I reviewed the first beta release of the new browser and gave it a resounding thumbs-down. Chances were, it seemed, the final release would suck louder than an aircraft toilet. But it doesn't. I eat my proverbial words. This is a decent browser and well worth a try, especially if you're currently using an old Netscape 4+ model.

It's not as fast as IE 5.5 and it's not going to topple the king from its throne, but it's good enough to secure a worthwhile slice of the market for Netscape. When combined with the Mozilla/Gecko final release, which should be out in a few months, that market share will be too large for any serious developer to ignore.

Most simple JavaScript works fine in N6. If, for example, you have links created in JavaScript or new windows that open and close, you should be OK. The main problem is if you get into the DOM (Document Object Model). The DOM for N6 isn't the same as for IE4+ or NN4. It's much closer to the W3C recommended DOM1 than either of these, but unfortunately that means the new browser won't accept a lot of DOM-related code already on the Net.
As a general rule, you're entering the realm of the DOM if you mess about with the properties of the Web page or the elements within it. If you don't change a property, you're probably not getting involved with the DOM.

Since the DOMs for IE and N4 were different even before N6 came along, most DOM-related code already recognises the browser (or, as some people say, parses the browser) and supplies separate lines of code for the main types.

If you're not very familiar with JavaScript, this is probably the easiest way to tell if your code will work in N6 unchanged or if it needs updating. Any scripts that devote their first few lines to recognising the browser will almost certainly need to be updated. In most cases they'll need a new section of code added that conforms with DOM1.

Changing the browser recognition element is relatively simple. Here's a detailed guide from WebReference.com and an alternative from Netscape.

The only problem is that after making these simple changes you will need to know what you're doing to rewrite code for DOM1. Note also that most DHTML code written by Dreamweaver and other DHTML authoring applications will need to be adjusted to work in N6.

Other Code

If you're using other proprietary code, this too will fail in N6, including NN4 proprietary code, most notably the use of Layers.
Here is a list of unsupported features:

Proprietary NN4 Features
document.layers[], document.elementName, and other NN4 Layer DOM features document.tags, document.ids, document.classes, or document.contextual() for setting CSS properties from NN4 JavaScript.LAYER, ILAYER, and MULTICOL elementsDIV SRC= transclusions (external content imported into an HTML page using "DIV SRC=...)"use of .jar files for SmartUpdate

Proprietary IE4/5 Features
document.all and other IE4/5 DOM featuresdocument.styleSheets[] for setting CSS properties from Internet Explorer JScriptMARQUEE and BGSOUND elements.cab files


Comments and observations on JavaScript coding for N6 are very welcome.

What is the difference between build and release?

Q: What is the difference between build and release?

A: Builds and releases are similar, because both builds and releases are end products of software development processes. Builds and releases are similar, because both builds and releases help developers and QA teams to deliver reliable software. A build is a version of a software; typically one that is still in testing.
A version number is usually given to a released product, but sometimes a build number is used instead.

Differences:
1."Build" refers to software that is still in testing, but "release" refers to software that is usually no longer in testing.

2."Builds" occur more frequently; "releases" occur less frequently.

3. "Versions" are based on "builds", and not vice versa. Builds (or a series of builds) are generated first, as often as one build per every morning (depending on the company), and then every release is based on a build (or several builds), i.e. the accumulated code of several builds.

SN.EXE - Code Strong Programs with Strong Names

From Dan Mabbutt,


In the article about gacutil.exe, the Global Assembly Cache utility, I mentioned that,
"Shared assemblies must have a "strong name" consisting of the name of the assembly, the version, a 64 bit hash of a public key (called a 'token') and the culture. To create a strong name for an assembly (that is, to generate a public/private key pair), you'll have to use another utility called sn.exe."

We're digging into the .NET Framework toolbox in this series, so in this article, we'll dig deeper into the strong name utility, sn.exe. There's a lot more to strong names and sn.exe.
You can think of a strong name as the .NET Framework equivalent of the old COM GUID. GUID expanded into "globally unique identifiers" and that was just about the only real advantage they had. They were just 128-bit numbers that were created by a mathematical process that made them unique. But strong names are created using two cryptographically related keys called the public key and the private key. This gives strong names a whole new dimension of capability over the old GUIDs.

Being more exact, a strong name consists of a set of related data as follows:

1. 
   The friendly name of the assembly-which is just the name of the assembly minus the file extension.
2. 
   The version number of the assembly.
3. 
   The public key value-created using sn.exe.
4. 
   An optional culture identity value used for localization.
5. 
   And perhaps most significant:
   An embedded digital signature that is created from a hash of the assembly's contents and the private key value. This is one big reason for having a 'strong name'. More on this later.

Before you can do any of this cool stuff, you first have to generate public/private key data using the .NET Framework utility: sn.exe. The sn.exe utility will create a file ending with the *.snk (Strong Name Key) file extension. This file contains the values of two mathematically related keys. These are the public key and the private key. The VB.NET compiler can record the full public key value in the assembly manifest.

The compiler will also generate a hash code based on the contents of the entire assembly including the IL (intermediate language) code and the metadata. A 'hash code' is a numerical value that can guarantee that the content of the assembly is the same. The hash code can be regenerated from the assembly and if the assembly isn't bit for bit identical, the hash value won't be the same. That means that if somehow any aspect of a .NET assembly has changed, the hash code will detect the change. The hash code is encoded by the private key data in the *.snk file to create a digital signature in the assembly's CLR header data.

The use of strong names goes way beyond the simple function of COM GUIDs and also provide protection against someone tampering with your assembly's contents. So it's a good idea to give every assembly a strong name, even if it isn't added to the GAC.

Note that the private key is not in the manifest. It's used to digitally sign the contents of the assembly (that's the process described above) but it isn't part of the manifest to maintain security. Public/private key cryptography can guarantee that no two organizations or individuals will have the same identity with .NET. But the most immediate effect goes back to where we started. Once a strong name is complete, the assembly can be installed into the GAC as a shared assembly.

Here's a quick demo of the process of generating and using a strong name.
We start off with our target utility, sn.exe as step 1! To create a public/private key file, open a Command Prompt window (and make sure you have changed the Windows Path using the SDKVARS batch file ... see the first article in this series for a detailed explanation). Change to a convenient directory - you might want to create a new one just to make things clean.

You can then generate a file named MySNFile.snk file using the command:
sn -k MySNFile.snk

You can use the public/private key pair that is contained in this file in any number of assemblies. Your whole company could use the same file, or you can create one just for your own work.

Now, create and complile a program ... any program ... using Visual Studio just as you ordinarily would. Switching back to the DOS box, use the ILDASM utility to view the manifest for the new assembly file for your program. Scroll down to the section of the manifest that describes your program. If your program is a standard Windows program named MyApp, the section will start with the line:
.module MyApp.exe

Because you're going to be looking for a change in the manifest, you might even want to copy this section into Notepad for easy comparison.

Close down ILDASM and go back to Visual Studio. Open the Solution Explorer window and notice that one of the files here is named AssemblyInfo.vb. This file describes the assembly itself. You can doubleclick it to open it in the Visual Studio edit window. To tell the VB.NET compiler to use the .snk file, you add the path to this file. And while you're updating this file, you probably should update the version information to something specific too. (A .NET version number is composed of the four parts "Major version.Minor version.Build number.Revision")

Switching back to ILDASM one final time, you will now see a new .publickey tag shows the full public key information.

And a .ver token should also have the version you added to the AssemblyInfo.vb file too.
In many real world situations, the actual .snk file for a whole organization could be a sensitive and protected file. In this case, you would use a technique called delayed signing which requires a slightly altered .snk file containing only the public key. Someone else with more security than you have will have executed sn.exe with a different parameter:

sn -p SecretCorporateKeyPair.snk PublicKeyForAnyone.snk

Then you would update AssemblyInfo.vb this way instead:

When you start using delayed signing, you have to disable the automatic signature verification when an assembly is deployed to the GAC. You do this by using the -vr flag with sn.exe to skip the verification process.
sn.exe -vr MyCoolCode.dll

Then, the person authorized to use the complete public/private .snk key file has to resign the the assembly with the complete digital signature. sn.exe has a parameter for that too - the -r flag:
sn.exe -r MyCoolCode.dll C:\SecretCorporateKeyPair.snk

The final step is to allow signature verification with the -vu flag:
sn.exe -vu MyCoolCode.dll

Application Security - Code Signing

Richard Lewis' application security notes for the software designer, developer and tester

What really is code signing?
At a high level, code signing allows you to generate a digital signature for the application binary and then provides a mechanism to carry the signature right to the end user. When the end user invokes the application, the digital signature is verified by the user and the user is able to make an informed decision whether the executable must be executed on his/her machine. Code signing uses digital signatures to provide identity and integrity for the code of software applications. It is important to understand that code signing merely asserts the identity of the software publisher and confirms that the software has not changed since it was signed. Code signing does not make a judgement of the quality of the software or its performance.



How does code signing work?
Let us now try and see how code signing works – Let us first understand the different entities involved in the code signing and verification process. The Software publisher obtains a code-signing certificate from the CA and uses the private key corresponding to the certificate to sign the code. The digital signature obtained is either embedded in the code or sent separately from the code (more on this later.) The software consumer who is typically the end user verifies the digital signature on the code before using the software. If the digital signature is verified successfully and the user trusts the signer of the software, he or she may go ahead and use the software. On the other hand, if the digital signature is not verifiable or the user does not trust the signer then he or she may choose to stop the application in its tracks. The bottom line is that code signing offers application designers a robust method of attaching their identity with the code that they write thereby providing greater user accountability and assurance.



What are some of the code signing technologies?
Microsoft offers two technology options for code signing – these are Authenticode and Strong Names.

Authenticode
Authenticode identifies the software publisher and confirms that the software has not changed since the signature was generated on it. It uses digital certificates as opposed to strong names which uses public keys. Therefore, authenticode allows software users to verify the identity of the software publisher up to a trusted root certificate or up to any certificate that the user trusts. Authenticode does not alter the executable portion of the application. Instead it supports embedded signatures wherein the digital signature is embedded in the non-execution portion of the executable. Examples where embedded signatures are used are in File Download box, the UAC prompt in Vista and the Windows loader. Authenticode also supports detached signatures in which signed catalog files are used to store the hashes of all files that require to be signed. The principal advantage of using detached signatures is when the file format does not support embedded signatures. Another advantage is performance as you have to sign (and verify) a group of files only once if you use detached signatures since the catalog files can reference several files at the same time. Authenticode is more prolific in terms of the number of the file formats that it supports viz. PE (.dll, exe, sys, ocx), Cabinet files and Windows installer files (.msi and .msp)

Strong Names
Strong name signing is used exclusively with .NET assemblies. Although digital signatures are used to generate strong names, it is important to understand that strong naming does not use digital certificate, instead it uses and supports public keys only. This means that it is not really possible to establish a chain of trust for the public key; and therefore there is no way to bind the identity of the software publisher to the private key being used to sign the assembly. Since strong names do not support digital certificates, they do not support expiration or revocation of key material either. This means that extra precautions must be taken by the software publisher to keep the private key private and to securely distribute the publisher’s public key to those assemblies that reference the signed assembly. In order to tide over these limitations, it is recommended that strong names be used along with authenticode, where possible.


What are the best practices for code signing?
Having now discussed the various options available for code signing let us now take a look at the best practices for code signing.

The first one is that you should use code-signing where you can. Code signing puts your product (and your organization) in the league of those organizations who are ready to run the extra mile in reassuring their customers about the reliability of their software. Code signing also tends to create a strong brand recall in the mind of your users when they are using their software. Its like having the About box of your software automatically pop up everytime the user runs your software!

We move on to the second one. Microsoft recommends that commercial software publishers use a different code-signing infrastructure to test sign pre-lease builds of their software. As part of this infrastructure, test publisher certificates must chain to completely different certificates than the root certificate this is used to sign the publicly released version of the software. Also it is much more efficient to use test signing rather than use signing for daily use during development. This helps in the configuration management space too as the using test certificates for signing ensure that pre-release code is not accidentally released to the public.

This point particularly applies to code that will be released to the public. As mentioned earlier, the keys used to generate and verify the signature on code are confidential items and therefore unless if the provided keys are not strongly authenticated, they must not be used for automatic code signing.

Strong naming does not use digital certificates and therefore does not support revocation and expiration. It is therefore imperative that the keys used for strong naming be protected in a failsafe manner.

To take care of the strong name shortcoming mentioned in the previous point, it is always a good idea to couple strong name signatures with authenticode signatures.
What are some of the tools for code signing?Having seen some of the best practices when using strong naming let us now see some tools that you can use for code signing.

MakeCat – This tool creates an unsigned catalog file that contains the hashes of a specialised set of files and their associated attributes. This allows an organization to sign a single file – the catalog – instead of signing numerous individual files. This tool relies on a catalog definition file (.cdf) that the user must create which contains the list of files to be cataloged and their attributes. The tool scans this file, verifies the attributes, adds the attributes to the catalog files and hashes and stores the hash values in the catalog file.

SignTool – This is a command line tool that signs, verifies and timestamps all formats supported by Authenticode. This tool is a well-endowed tool in that it can sign and verify signatures, check if certificates are revoked and also wheter a signing certificate is valid for a specific policy.

Strong Name Tool (sn.exe) – This tool is used to sign .NET assemblies. It also allows for key management, signature generate and signature verificateion and supports strong name test signing , delay signing and release signing.