Hi All. We have been debugging an issue in our product that triggered a BSOD. We usually analyze them using a Kernel Memory Dump so we set our machines for that.
Our analysis led us to the Microsoft iSCSI initiator driver, and we needed their help troubleshooting why a specific IRP was not completing there.
We opened a ticket with Microsoft support, our engineers went back and forth to set a time to talk about it. Finally, they asked us to upload the memory dump.
All that to get this answer from them after doing so (verbatim):
Hello XXXXXXX
Thanks a lot for your patience and understanding on the call. As discussed, for us to initiate a Dump Analysis which will be performed by an Escalation Engineer, the memory dump needs to be a Complete Memory Dump rather than a Kernel Memory Dump. However, since you only have a Kernel Memory Dump for the Bugcheck that occurred and only the System and Application Events for that day, we will not have any scope for further analysis on this.
Hence as agreed I will proceed with the Archival of this ticket as unsupported. And you will receive a Refund for this ticket.
If you have any further queries, feel free to reply on this Email chain.
Thanks a lot for choosing Microsoft Support!!
Rxxxxx Dxxxx
Microsoft Support Engineer | Email : x-xxxxxx@microsoft.com
Windows Storage & High-Availability Professional Team
Working Hours : Monday–Friday : 08:00 AM – 05:30 PM IST
I am surprised that Microsoft drops the ball when the issue we wanted them to look at is an IRP stuck in their iSCSI initiator (kernel mode driver), and I cannot comprehend why ONLY a Complete Memory Dump can be used to troubleshoot this.
Did you have the same experience? Can we push back to make them look at this dump anyway?
At the risk of stating the obvious, collect a full memory dump and open a new ticket.
There is a perverse incentive within support organizations to 'close tickets'. The first level support people generally get evaluated by the number of tickets they close rather than their ability to solve problems.
My experience with Microsoft support is that once you manage to push through the first level you get pretty decent support from the engineers at higher levels.
The first level support folks don't understand what's necessary. But it's probably been drilled into them that they can't forward mini-dumps for analysis by Escalation.
It'll probably be easier to just send them a full memory dump, as Mr @Mark_Roddy suggested, than to argue with them enough to convince them that they don't NEED a full memory dump and that a kernel dump is entirely sufficient.
If you can reproduce the problem and collect a full memory dump, then that's the easiest path. But if you can't reproduce the problem and all you have is a kernel dump, then you have to push them for more.
It should be noted that this is not just a MSFT issue. Every large vendor that I have ever worked with has the same problem.
One method is to burry them with technical details about their own product so that the level 1 'engineer' knows they aren't dealing with a 'did you plug it in?' type problem
Thank you all for your input. The people in charge of submitting this dump to Microsoft did not push to have them look at it so, in the future, we will have to turn all our machines to collect full dumps. Those could be huge on systems we have with 512 GB of RAM but MS must have a great upload site!
What amazes me is the fact that we got them a Kernel Memory dump, not just a mini-dump and we wanted them to investigate a stuck IRP in their iSCSI initiator driver, which is all in kernel memory.
Question: would OSR perform such (paid) investigation in-lieu of MS if you have the adequate symbols, MS source, etc?
Thank you.
That question is commercial in nature, and thus banned from this forum.
If you have any questions about OSR products or services, you are most welcome to drop a quick note to our business team (sales at OSR dot com). They’ll be happy to answer whatever questions you may have.