In itemupdating event
Although asynchronous events expose a SPItem Event Properties parameter named properties just like their synchronous counterparts, remember that the operation has already completed so you cannot modify anything in the properties parameter (well, you can, but it doesn’t do anything).
Additionally, the properties parameter may not be populated with information that you would tend to expect to be present.
Before you can deploy the event receiver you have to change the file to bind the Update Adding event receiver to all custom lists.
Remember that if you want to develop event receivers for specific lists, you will have to work with content types.
Later on, when you checked the document in, you would see those events fire again.
So the double-event firing isn’t a bug, it’s just a result of the automatic check-in that occurs when you first add a document to a document library.
Do NOT try to manually get the list item in code and update a property on it because the optimistic locking mechanism in Share Point may throw an error later on when the operation associated with the event to which you are responding attempts to complete.
If you find yourself in this situation, then you’ll have to solve the problem in code.
Fortunately, there is a relatively simple way to check whether the Item Updating and Item Updated events are firing in response to a check-in outlined in Knowledgebase Article 939307.
The first time the Item Updating and Item Updated events fire it is in response to the document properties changing.
The second time they fire it is in response to the document being checked in.