Incomprehensible Deadlock Case

My Evn:
windows 2003 server x64 + sql server 2008 sp2 Enterprise X64

example:

The deadlock condition results when two processes executing the same statement at same time in hight concurrency:

update tt with(rowlock) set c='eb',d='cc' 

where a='84B23855-2155-4EE0-911D-38D1265F1655'

 

table structure :

use tempdb

go

create table tt(id int identity primary key,a char(36),b char(36),c varchar(max) ,d char(200))

go

insert into tt select NEWID(),'bbb','ccc','ddd'

go 10000



create index ix_a_bc on tt(a)include(b,c)

 

check the updata statement infomation with profiler,here is the infomation about the relaease of lock request:

Open a new session,spid=58

update tt with(rowlock) set c='eb',d='cc' 

where a='84B23855-2155-4EE0-911D-38D1265F1655'

 

with the profiler:

 

from the results:the update statement. first, a non-clustered index "ix_a_bc" getting the hash cord is "2b02a7cba37c" record using "a=84B23855-2155-4EE0-911D-38D1265F1655".And add the U-lock,then add the X-lock,after that add X-lock for "2b02a7cba37c".

During this process we konw,the non-clustered and the clustered key were added U-lock and X-lock.The other processes of update for this record have to wait for the lock released. 

 

I added another index for the table:

create index ix_b_cd on tt(b)include(c,d)

 

execut the update statement again,with the profiler:

 

from the results:we got the clustered key is "520072b6acb1",and added U/X-lock on.After that the incomprehensible thing occurred,even released the U-lock on non-clustered key "2b02a7cba37c",then added another X-lock on non-clustered key "2b02a7cba37c".

ok,if the other update processes accessing "2b02a7cba37c" ,between release the U-lock and add the X-lock on "2b02a7cba37c",and add U-lock on it.What will happen??

 

I test this case.In two session,I run the update statement at the same time,my spid are 54 and 58.

by the picture i found:Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

with the profiler:

 

from the results:Two processes run simultaneously,process 54 added U-lock on non-clustered key "2b02a7cba37c" first,then got the clustered key "520072b6acb1",and added U/X-lock.after that,it released the U-lock on "2b02a7cba37c".At the same time,the process 58 accessed,and added the U-lock on "2b02a7cba37c".Next,the process 58 will add U-lock on clustered key "520072b6acb1",but the process 54 added X-lock on it and not released,because the process 54 waited for adding X-lock on non-clustered "2b02a7cba37c" that the process 58 added U-lock on already.
So,deadlock.look at the picture below:

 

In this case,sql server will find the deadlock,and kill a process automatically.In this example,the process 54 was killed.The process 58 got the clustered key "520072b6acb1",and added U-lock and X-lock.Then released U-lock on "2b02a7cba37c",added X-lock on it again.After that,release all lock.The process 58 updated successful.look at the picture:

In normal condition,it won't get deadlock by update the same thing at the same time for one record.In this case,I tested a lot,and found the reason.
Satisfy the following three conditions, the problem occurs:
1.the non-clustered index must includes the column type  varchar(max)
2.the varchar(max) column must in the update statement ,and satisfied with condition 1
3.the table must have more than 2(include 2) non-clustered indexes include the same column satisfied the conditon 1 and 2.

Is it a bug ,or not?I am so confused.why for varchar(max) will be different?