MessageQueueException in ReadHandle
Andrew Hayes
I've got some code that enumerates the public message queues on various remote servers and I've run into a snag...
First, here's a code snippet that is mostly working:
MessageQueue[] qList = MessageQueue.GetPublicQueuesByMachine( mName );
foreach(MessageQueue queueItem in qList)
{
try
{
queueItem.Formatter = new BinaryMessageFormatter();
queueItem.MessageReadPropertyFilter.SetAll();
MessageEnumerator myEnumerator = queueItem.GetMessageEnumerator();
while(myEnumerator.MoveNext())
{
try
{
mMessageCount++;
}
catch (Exception exp)
{
MessageBox.Show( exp.Message, "Error Getting Message" );
}
}
}
catch (Exception exp)
{
MessageBox.Show( exp.Message, "Error Getting Queue" );
}
MessageBox.Show( queueItem.Path + ":" + mMessageCount, "Message Count for Queue" );
}
OK. For most of the servers this works great... Except for 1. It's a newly installed Windows 2003 Server and the myEnumerator.MoveNext() call throws a MessageQueueException with no message text...
Well, I say that but the _message element says "External component has thrown an exception." and _stackTraceString shows:
at System.Messaging.MQCacheableInfo.get_ReadHandle()
at System.Messaging.MessageEnumerator.get_CursorHandle()
at System.Messaging.MessageEnumerator.MoveNext(TimeSpan timeout)
at System.Messaging.MessageEnumerator.MoveNext()
at QueueMonitor.EnumerateQueues() in c:\projects\queuemonitor\queuemonitor.cs:line 59
So, I put in a breakpoint on the queueItem.Formatter line and hit Shift+F9 to QuickWatch queueItem... That's when I noticed:
ReadHandle <error: an exception of type: {System.Messaging.MessageQueueException} occurred>
I step through to after the myEnumerator construction and take a look at that:
Handle 0
Current <error: an exception of type: {System.InvalidOperationException} occurred>
CursorHandle <error: an exception of type: {System.Messaging.MessageQueueException} occurred>
Seems I can't get the Handle for the Message Queue, which in turn means I can't get a Handle for the Enumerator... So I checked the security on the remote public queue I was enumerating and ( like everyone else on these NG's seems to do ) it was set to Everyone - Full Control... My machine and the remote machine both belong to the same Active Directory domain, and DNS is correctly setup for that to work... I believe...
Looking at the Exception instance I also see:
_COMPlusExceptionCode -532459699
_HResult -2147467259
MessageQueueErrorCode -2147023071
Searching for 0x80070721 (-2147023071) seems to indicate it's a DCOM Automation error to do with security packages, so maybe there is something extra I need to do in 2K3 to allow me to enumerate the messages in the public queues...
Anyone have any thoughts, comments, ideas, suggestions or, preferably, solutions?
![Yoel Arnon [MSFT]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Yoel Arnon [MSFT]
There seems to be some kind of authentication problem between your
Windows2003 server and the domain controller. The problem occurs in the
Active Directory access layer "under" MSMQ.
I would check the following:
1. Can you see the queues when running Active Directory Users and Computers
from the Windows 2003 box?
2. Does your program run as a service / ASP / COM+ component / Cluster
resource orany other special security context?
3. When you installed MSMQ, did it ask you for a DS server? (If it did, it
cannot locate the Active Directory through DNS, and it uses the old MSMQ 1.0
/ 2.0 interface)
4. Is your DNS configured right? (simple test: ping your DC using its short
netbioos name, and see if ping says "pinging <netbios name>" or "pinging
<full DNS name>. The former usually means that DNS is not configured right.
HTH,
Yoel
---
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:6E3E14EB-CA46-4E2A...@microsoft.com...
Andrew Hayes
Thanks for the reply. In order to convey more information I am going to focus on 3 machines...
2003SA - The Windows 2003 Server Standard Edition that I am developing on.
2003SB - The newly installed Windows 2003 Server Standard Edition member server.
2000DC - The Windows 2000 Server Active Directory Domain Controller (and DNS Server of course)
All 3 machines are members of the domain controlled by 2000DC, which we'll call DOMAIN.
My answers to your questions are as follows:
1. Can you see the queues when running Active Directory Users and Computers from the Windows 2003 box?
2003SA and 2003SB do not show Active Directory Users and Computers under Adminstrative Tools. I have to go through the MMC and add the Snap-in... In the end I don't see any queues there, only MSMQ Users.
When I use Computer Management from 2003SA/2000DC and connect to 2003SB I do not see Message Queuing under the Services and Applications tree, but if I use Computer Management from 2003SB and connect to 2003SA/2000DC I can see Message Queuing and the underlying queues.
This would imply that 2003SB is hiding MSMQ settings even from the admin account via 2000DC... I do not know where this is changed.
2. Does your program run as a service / ASP / COM+ component / Cluster resource or any other special security context?
No. It's a standard Visual C# .NET Windows Application.
3. When you installed MSMQ, did it ask you for a DS server? (If it did, it cannot locate the Active Directory through DNS, and it uses the old MSMQ 1.0 / 2.0 interface)
2003SB did not ask for a DS server, and I don't recall whether 2003SA did. I believe that in both cases the machines were members DOMAIN and the 2000DC admin account had been used to logon.
4. Is your DNS configured right? (simple test: ping your DC using its short netbioos name, and see if ping says "pinging <netbios name>" or "pinging <full DNS name>. The former usually means that DNS is not configured right.
Pinging 2000DC from 2003SB shows the fully qualified 2000DC.DOMAIN name.
If you have any further thoughts, or ways that I can extract more detailed information, please feel free to post.
Frank Boyne
> 2003SA and 2003SB do not show Active Directory Users and
> Computers under Adminstrative Tools. I have to go through the
> MMC and add the Snap-in... In the end I don't see any queues
> there, only MSMQ Users.
If I recall correctly, Active Directory tools are only automatically
installed on Domain Controllers. Find adminpak.msi on your Windows
Server 2003 CD and install that to get the admin tools installed on
non domain controllers.
Your having to add the snap-in sounds wrong.
> When I use Computer Management from 2003SA/2000DC
> and connect to 2003SB I do not see Message Queuing under
> the Services and Applications tree, but if I use Computer
Management
> from 2003SB and connect to 2003SA/2000DC I can see
> Message Queuing and the underlying queues.
It might be worth comparing the MSMQ installs on those two systems.
Run Add/Remove Programs and select Add/Remove Windows Components and
then select Application Server and click on details - are the MSMQ
components installed on 2003SA and 2003SB the same?
> This would imply that 2003SB is hiding MSMQ settings
> even from the admin account via 2000DC.
Or else it is having problems communicating with 2000DC, or
accessing data in AD on 2000DC and so can't display the settings?
Doron Juster [MSFT]
"In the end I don't see any queues there, only MSMQ Users." ?
Do you see a container called "MSMQ Users" ?
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:23D91C0C-50FD-4401...@microsoft.com...
Andrew Hayes
OK. For the MSMQ setup, both 2003 machines show Active Directory Integration and Common as installed.
If 2003SB was having problems with Active Directory or 2000DC then surely the MSMQ tree for 2000DC would be unavailable when using Computer Management on 2003SB? I can see the 2000DC Message Queuing tree from 2003SB, but I can't see the 2003SB Message Queuing tree from 2000DC.
The AD Domain Admins group is a member of the 2000SB Administrators group, and in all cases I logon to the machines using an AD Domain Admin account.
Anything else I should look at?
Doron Juster [MSFT]
Any error events from msmq in the applications events log (on 2003SB) ?
Reading through this thread and your other posts I start thinking that the
msmq service is not running on 2003SB. In that case, you can still use
computer management to view the msmq tree on other computers (which do run
msmq). But you won't be able to expand a remote queue and see its messages.
And you won't be able to see the local msmq tree.
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:9194EFB0-D4B9-4889...@microsoft.com...
Andrew Hayes
Thanks for the assistance so far. Here's some more info:
In Computer Management, connected locally on 2003SB, I can see the Message Queuing tree and I can create, delete, and purge public and private queues. I can also see the messages that were sent from 2003SA via the Diagnostics "Send test messages" feature, as I was able to create a public queue on 2003SB using the "New Queue..." button on the Send test messages dialog from 2003SA.
I can programmatically enumerate the public and private queues on 2003SB from 2003SA but I cannot enumerate the messages in the queues because of the exception thrown by System.Messaging, as detailed in my first post in this thread, so I would say that MSMQ is running on 2003SB, but with some security or other issues that I have not yet been able to identify.
What I will do is code another test program to use the various programmatic methods for remotely enumerating and creating queues; sending, peeking and reading messages; etc., and see which ones fail, and how they fail.
Regards...Andrew
Frank Boyne
> Anything else I should look at?
The only other thing I can think of is turning on some of the
diagnostics described in the MSMQ FAQ troubleshooting section. The
FAQ can be found here:
http://www.microsoft.com/windows2000/technologies/communications/msmq/wp_msmqfaq.asp
These diagnostics are really for Microsoft to use, but sometimes us
mere civilians can also get some idea of what is going wrong :-)
Doron Juster [MSFT]
Essentially, you're concerned with:
I can programmatically enumerate the public and private queues on 2003SB
from 2003SA but I cannot enumerate the messages in the queues because of the
exception thrown by System.Messaging
And you refer to error 0x80070721 (from your first post). In other posts you
mentioned that you're logon as a NT4 user (from a NT4 domain which has
bi-directional trust with the Active Directory forest).
I have one more question, trying to fully understand the scenario.
How are you logged on 2003SA when you fail to read from 2003SB ? as a NT4
user or as a Active Directory domain user ?
I ask this because 0x80070721 may indicates a problem with rpc
authentication. RPC is used by msmq for remote read. If you're logged on as
NT4 user, then msmq fall back to NTLM authentication. If you're logged as a
Active Directory domain user then msmq may use rpc with encryption and
Kerberos.
Can you try same operation that fail while logged on once as NT4 user and
then as Active Directory user ?
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:A278BC06-6A58-4BA7...@microsoft.com...
Andrew Hayes
Sorry for the delay in replying.
If I login to 2003SA using the AD Domain Admin account I can programmatically enumerate the messages on 2003SB, and it doesn't throw the exception.
This points the finger at some form of authentication issue, but it is limited to 2003SB as I can enumerate the messages on all the 2000 boxes in the AD domain using my NT login.
Changing the logon to an AD account is not really the solution as I can programmatically enumerate the queues on 2003SA from 2003SB, and I can't give all the users, that use my application, AD domain logons.
In both the NT and AD login cases, I cannot remotely see the Message Queuing tree in Computer Management. Only by using Computer Management locally do I see the tree and the various queues.
Doron Juster [MSFT]
messages from 2003SA using a NT4 account ? Start netmon before you try the
scenario and set netmon to capture full frames. Filter only tcpip traffic
to/from 2003SB. Then please post the capture and I'll take a look.
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:ADF0ED21-063C-4882...@microsoft.com...
Andrew Hayes
2 4.769669 MAC2003SA LOCAL MSRPC c/o RPC Response: call 0x3 context 0x0 hint 0x4 cancels 0x0 2003SB 2003SA IP
3 4.769669 LOCAL MAC2003SA MSRPC c/o RPC Request: call 0x4 opnum 0x4 context 0x0 hint 0x8 2003SA 2003SB IP
4 4.769669 MAC2003SA LOCAL MSRPC c/o RPC Response: call 0x4 context 0x0 hint 0x30 cancels 0x0 2003SB 2003SA IP
5 4.769669 LOCAL MAC2003SA TCP Control Bits: ....S., len: 0, seq:4004545326-4004545327, ack: 0, win:16384, src: 4146 dst: 2103 2003SA 2003SB IP
6 4.769669 MAC2003SA LOCAL TCP Control Bits: .A..S., len: 0, seq:1649502795-1649502796, ack:4004545327, win:65535, src: 2103 dst: 4146 2003SB 2003SA IP
7 4.769669 LOCAL MAC2003SA TCP Control Bits: .A...., len: 0, seq:4004545327-4004545327, ack:1649502796, win:17520, src: 4146 dst: 2103 2003SA 2003SB IP
8 4.769669 LOCAL MAC2003SA TCP Control Bits: .A...F, len: 0, seq:4004545327-4004545328, ack:1649502796, win:17520, src: 4146 dst: 2103 2003SA 2003SB IP
9 4.769669 MAC2003SA LOCAL TCP Control Bits: .A...., len: 0, seq:1649502796-1649502796, ack:4004545328, win:65535, src: 2103 dst: 4146 2003SB 2003SA IP
10 4.769669 MAC2003SA LOCAL TCP Control Bits: .A...F, len: 0, seq:1649502796-1649502797, ack:4004545328, win:65535, src: 2103 dst: 4146 2003SB 2003SA IP
11 4.769669 LOCAL MAC2003SA TCP Control Bits: .A...., len: 0, seq:4004545328-4004545328, ack:1649502797, win:17520, src: 4146 dst: 2103 2003SA 2003SB IP
12 4.769669 LOCAL MAC2003SA MSRPC c/o RPC Request: call 0x4 opnum 0x0 context 0x0 hint 0x0 2003SA 2003SB IP
13 4.769669 MAC2003SA LOCAL MSRPC c/o RPC Response: call 0x4 context 0x0 hint 0x4 cancels 0x0 2003SB 2003SA IP
14 4.769669 LOCAL MAC2003SA MSRPC c/o RPC Request: call 0x6 opnum 0x2 context 0x1 hint 0x3C 2003SA 2003SB IP
15 4.769669 MAC2003SA LOCAL MSRPC c/o RPC Fault: call 0x6 context 0x1 status 0xC00E0007 cancels 0x0 2003SB 2003SA IP
16 4.972794 LOCAL MAC2003SA TCP Control Bits: .A...., len: 0, seq:2349021129-2349021129, ack:3301909131, win:17196, src: 4143 dst: 2103 2003SA 2003SB IP
17 4.972794 LOCAL MAC2003SA TCP Control Bits: .A...., len: 0, seq:1063955812-1063955812, ack:3293932942, win:17348, src: 4142 dst: 2105 2003SA 2003SB IP
Andrew Hayes
15 4.769669 MAC2003SA LOCAL MSRPC c/o RPC Fault: call 0x6 context 0x1 status 0xC00E0007 cancels 0x0 2003SB 2003SA IP
FRAME: Base frame properties
FRAME: Time of capture = 2004/03/16 11:38:57
FRAME: Time delta from previous physical frame: 0 microseconds
FRAME: Frame number: 15
FRAME: Total frame length: 86 bytes
FRAME: Capture frame length: 86 bytes
FRAME: Frame data: Number of data bytes remaining = 86 (0x0056)
ETHERNET: EType = Internet IP (IPv4)
ETHERNET: Destination address = 00065B496701
ETHERNET: 0....... = Individual address
ETHERNET: .0...... = Universally administered address
ETHERNET: Source address = 00C09F1D095A
ETHERNET: .0...... = Universally administered address
ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4))
IP: Protocol = TCP - Transmission Control; Packet ID = 1337; Total IP Length = 72; Options = No Options
IP: Version = IPv4; Header Length = 20
IP: 0100.... = IP Version 4
IP: ....0101 = Header Length 20
IP: Type of Service = Normal Service
IP: 000..... = Precedence - Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: .....0.. = Normal Reliability
IP: ......0. = Normal Monetary Cost
IP: Total Length = 72 (0x48)
IP: Identification = 1337 (0x539)
IP: Fragmentation Summary = 16384 (0x4000)
IP: .1.............. = Cannot fragment datagram
IP: ..0............. = Last fragment in datagram
IP: ...0000000000000 = Fragment Offset 0 (0x0000)
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP - Transmission Control
IP: Checksum = 0 (0x0) (Error)
IP: Source Address = 2003SB
IP: Destination Address = 192.168.0.52
TCP: Control Bits: .AP..., len: 32, seq:3301909099-3301909131, ack:2349021129, win:65159, src: 2103 dst: 4143
TCP: Source Port = 0x0837
TCP: Destination Port = 0x102F
TCP: Sequence Number = 3301909099 (0xC4CF226B)
TCP: Acknowledgement Number = 2349021129 (0x8C0337C9)
TCP: Data Offset = 20 bytes
TCP: 0101.... = Data Offset (20 bytes)
TCP: ....0000 = Reserved bits
TCP: Flags = 0x18 : .AP...
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....1... = Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 65159 (0xFE87)
TCP: Checksum = ERROR: CheckSum is 0x8263, Should be 0xF6CA
TCP: Urgent Pointer = 0 (0x0)
TCP: Data: Number of data bytes remaining = 32 (0x0020)
MSRPC: c/o RPC Fault: call 0x6 context 0x1 status 0xC00E0007 cancels 0x0
MSRPC: Version = 5 (0x5)
MSRPC: Version (Minor) = 0 (0x0)
MSRPC: Packet Type = Fault
MSRPC: Flags 1 = 3 (0x3)
MSRPC: .......1 = Reserved -or- First fragment (AES/DC)
MSRPC: ......1. = Last fragment -or- Cancel pending
MSRPC: .....0.. = Not a fragment -or- No cancel pending (AES/DC)
MSRPC: ....0... = Receiver to repond with a fack PDU -or- Reserved (AES/DC)
MSRPC: ...0.... = Not used -or- Does not support concurrent multiplexing (AES/DC)
MSRPC: ..0..... = Not for an idempotent request -or- Did not execute guaranteed call (Fault PDU only) (AES/DC)
MSRPC: .0...... = Not for a broadcast request -or- 'Maybe' call semantics not requested (AES/DC)
MSRPC: 0....... = Reserved -or- No object UUID specified in the optional object field (AES/DC)
MSRPC: Packed Data Representation
MSRPC: Fragment Length = 32 (0x20)
MSRPC: Authentication Length = 0 (0x0)
MSRPC: Call Identifier = 6 (0x6)
MSRPC: Allocation Hint = 32 (0x20)
MSRPC: Presentation Context Identifier = 1 (0x1)
MSRPC: Cancel Count = 0 (0x0)
MSRPC: Reserved = 0 (0x0)
MSRPC: Status = 3222142983 (0xC00E0007)
MSRPC: Reserved 2
00000: 00 06 5B 49 67 01 00 C0 9F 1D 09 5A 08 00 45 00 ..[Ig..ÀŸ..Z..E.
00010: 00 48 05 39 40 00 80 06 00 00 C0 A8 00 A4 C0 A8 .H.9@.€...À¨.¤À¨
00020: 00 34 08 37 10 2F C4 CF 22 6B 8C 03 37 C9 50 18 .4.7./ÄÏ"kŒ.7ÉP.
00030: FE 87 82 63 00 00 05 00 03 03 10 00 00 00 20 00 þ‡‚c.......... .
00040: 00 00 06 00 00 00 20 00 00 00 01 00 00 00 07 00 ...... .........
00050: 0E C0 00 00 00 00 .À....
Doron Juster [MSFT]
UUID of each rpc call.
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:295D92BE-603A-4D9A...@microsoft.com...
> 00000: 00 06 5B 49 67 01 00 C0 9F 1D 09 5A 08 00 45 00 ..[Ig..?Ÿ..Z..E.
> 00010: 00 48 05 39 40 00 80 06 00 00 C0 A8 00 A4 C0 A8 .H.9@.?...?¨.¤?¨
> 00020: 00 34 08 37 10 2F C4 CF 22 6B 8C 03 37 C9 50 18 .4.7./??"kŒ.7?P.
> 00030: FE 87 82 63 00 00 05 00 03 03 10 00 00 00 20 00 ???c.......... .
> 00040: 00 00 06 00 00 00 20 00 00 00 01 00 00 00 07 00 ...... .........
> 00050: 0E C0 00 00 00 00 .?....
>
Doron Juster [MSFT]
case and provide the capture and all the details of your environment.
Thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:7AE6E89E-18BC-4F85...@microsoft.com...
> Sorry Doron, but I can't post attachments to these newsgroups, although if
you give me an email address I can send it to you.
Doron Juster [MSFT]
Microsoft support in the USA and get support in English. This happens
frequently.
Due to time zone differences, they suggest you start by opening a web-based
call from http://support.microsoft.com
Please let me know if you encounter any problems with this.
thanks, Doron
--
This posting is provided "AS IS" with no warranties, and confers no rights.
.
"Andrew Hayes" <anon...@discussions.microsoft.com> wrote in message
news:CCC77FE7-FCA7-417C...@microsoft.com...
> Unfortunately, that's not a realistic option as they don't do English
support in Japan and the US support won't support me if I'm not in the US,
hence my reliance on the newsgroups, but thanks for the help so far. I'll
see if I can work out why that MSRPC call is failing, although I don't see
any UUID's even when browsing the capture file with Network Monitor.