That is very strange , in your case the problem does not 
seem to be the queue or msgQRecieve .I would go through the 
following checklist :

1)What is the priority given to task A ? Is it high enough 
when compared to other coexisting tasks ? If the priority 
is very low then A wouldnt get executed often enough to 
clear the queue (with task A being the only reader) , the 
queue would get full and B would time out if it is 
WAIT_FOREVER .

2)Make sure you are reading from the right queue.

I can't think of anything else , please let me know if you 
have already found a solution to your problem.

Thanks Gaurav for ur answer. But if B is using WAIT_FOREVER,
it should never timed out, right? Also, all application
tasks are runnig n at same priority in preemptive manner.
Anyhow, in this case, I found that qJobGet() of vxworks is a
lower level generic function which is used by many other
routines including msgSend. If this is the case, I am trying
out following:
1. I am trying to get a stack dump of this task. Though it
would involve lot of labour but I am hoping to take a dump
of valid addresses that I found in its stack. This should
help in obtaining actual caller of qJobGet(). This way, we
might find the resource our task A is actually wai6ting for
to acquire(it should be either of some vxworks semaphore or
msgQ itself).
2. Second, I found that task structure of vxworks contains a
 variable that stores the address of the object task is
currently PENDed on. If that address can be dumped, again we
can hope to progress from here.
Unfortunately am using an older version of vxworks and can
not afford to upgrade to later versions. So, many of the
utilities found on web have to be actually written using 
available vxworks's online tools.