Where to submit a "your driver or mine? ticket" - sysdev or developer.microsoft.com

OK so something procedural, but hopefully someone here will have been there, done that and be able to show me their t-shirt …

There’s an issue where when our driver is installed, and there’s a specific (windows) setup, there’s a BSOD in a windows driver.

We raised a premier support ticket with MS to try to find out what changes we need to make to stop this (because as we all know, even if it’s a bug in one or more MS drivers and it gets fixed, not everyone patches … so you still need to know which bits of *your* driver you change to tiptoe round the problem. And if it’s your problem then you need to know what to change, full stop).

We’ve been told to raise something with sysdev. Or possibly developer.microsoft.com.
They don’t seem sure.

The latest advice has been to search
https://developer.microsoft.com/en-us/windows/support
for “driver” and use what comes up to work out what to do next.

I raised an eyebrow at this - I mean it is a very specific, reproducible issue, we’ve even uploaded a memory dump - surely someone knows in more detail where we register this and what information we should provide. I’ve been back and forth with various folks including our P.Support account manager in Microsoft and just nobody there seems to know.

Anyone here know?

I just want to get the issue to someone who can give us a useful analysis & followon advice, and I *know* they do exist in MS - we’ve had positive experiences before with similar queries.

Sadly, I don’t know, though if you find the secret sauce I’m sure it would
be very useful to the community.

Unrelated, but in the meantime I’d be happy to take a shot at looking at the
dump for you. Can’t say that I’ll be able to tell you what you need to know,
but it’s a hobby of mine :slight_smile:

Regards,

-scott
OSR
@OSRDrivers

“%%merge inmail_.HdrFromSpc_%%” wrote in message news:xxxxx@ntdev…

OK so something procedural, but hopefully someone here will have been there,
done that and be able to show me their t-shirt …

There’s an issue where when our driver is installed, and there’s a specific
(windows) setup, there’s a BSOD in a windows driver.

We raised a premier support ticket with MS to try to find out what changes
we need to make to stop this (because as we all know, even if it’s a bug in
one or more MS drivers and it gets fixed, not everyone patches … so you
still need to know which bits of *your* driver you change to tiptoe round
the problem. And if it’s your problem then you need to know what to change,
full stop).

We’ve been told to raise something with sysdev. Or possibly
developer.microsoft.com.
They don’t seem sure.

The latest advice has been to search
https://developer.microsoft.com/en-us/windows/support
for “driver” and use what comes up to work out what to do next.

I raised an eyebrow at this - I mean it is a very specific, reproducible
issue, we’ve even uploaded a memory dump - surely someone knows in more
detail where we register this and what information we should provide. I’ve
been back and forth with various folks including our P.Support account
manager in Microsoft and just nobody there seems to know.

Anyone here know?

I just want to get the issue to someone who can give us a useful analysis &
followon advice, and I *know* they do exist in MS - we’ve had positive
experiences before with similar queries.

Thanks Scott - a tempting offer (who doesn’t love a tasty memory dump!) but as it turns out things have moved on very quickly today!

As luck would have it my colleague at the next desk received a BSOD dump crashing in the same place and with very similar stack frames above that - but triggered apparently by a usermode program calling DeviceIoControl. The driver I help look after wasn’t installed, and there was no obvious involvement from our other driver which was loaded. I’ve gone back to Microsoft and asked how we treat it now, given that the above suggests it is a Windows bug.

From my rummaging about I wonder if there is some issue with irp stack locations but we’ll see.

I still don’t know what “slot” it goes in but will update if (hopefully when) I find out …

That’s ridiculous. Sysdev doesn’t handle these issues, and neither does the hardware dashboard… which is sysdev by a different name.

With all due respect to all involved, there are people in the Support organization who are *more* than capable of helping with this, and *have* helped with issues like this for other vendors. There are people in the Support org who are even trained in driver development. The Support org is *supposed* to triage this problem and then get it to the right folks in the Product Group (that is, the PMs and Engineers) to identify the issue.

If they’re saying “Driver stuff? Not my table!!” that is emphatically not how the Support organization is SUPPOSED to work… or at least, not how it HAS worked in the recent past. We’ve had clients get *very* good, in-depth, even impressive support for driver issues from MSFT Support in the past.

Sooooo… if your current path doesn’t work for you, I’d suggest you push-back on whoever you’re interfacing with. “Go find somebody else in MSFT to talk to” isn’t what your Premier Support dollars are supposed to get you.

Peter
OSR
@OSRDrivers

Yes, that’s what I thought too :slight_smile:

Update: After pushing back via our TSAM (politely, my manager was cc’d on the thread and found it very amusing) it got moved to someone suitable aaaaand it appears that indeed it is a MS bug and also the sort of thing I thought it might be from peering at the disassembly (an IO stack location issue).

We had a face-to-face chat with our TSAM this morning and there might be some improvements coming both in guidance re raising cases and routing of cases once they’re in the system.

Great!

Thanks for posting back. I hope it actually gets worked out.

Like I said, I have seen some *very* impressive support for system level software provided via the MSFT support organization. But, SOMEtimes… you need to push to engage with the right folks. Not every TAM/TSAM is trained in or aware of driver-related issues.

Anyhow… glad to hear you’re making progress,

Peter
OSR
@OSRDrivers