I recently created some partitioned queues from where I send and receive all the time. They\'ve run as non-partitioned in the past without any of my current issues.
I have seen a similar thing in our production env - maybe its the same behavior you are seeing. Using ServiceBusExplorer or something similar, check if the message's 'ContentType' = application/vnd.ms-servicebus-ping.
If so... this is a (Azure) system generated message to determine queue availability... as far as I know these messages are supposed to disappear after they are received... but mine do not either. The documentation from MS is sparse on this stuff...
In any case, if you make sure that this is the cause, you can at least rest assured that they are not YOUR messages that are stuck in ServiceBus purgatory. Hopefully MS fixes this soon...
From Service Bus explorer you can check these messages and the state of them, they might be in deferred state. To know more about deferred state read this.
"When a queue or subscription client receives a message that it is willing to process, but for which processing is not currently possible due to special circumstances inside of the application, it has the option of "deferring" retrieval of the message to a later point. The message remains in the queue or subscription, but it is set aside."
Found this question while looking into an issue with messages stuck in a topic subscription. Messages were visible in Azure Portal and Service Bus Explorer but not being picked up by my application using the RegisterMessageHandler function.
This was resolved after toggling the Topic state to Disabled and then back to Active.
Check the lock duration of your queue. If the Messages had been received but not marked as Complete() they seem to be "stuck" (not receivable) until the lock releases the Message again.