Any stack address that is returned from a called function to a calling function. A trivial example (in the real world it can be much more complex)

void func1()
{
char* pBuf;

pBuf = func2();

func3(pBuf);

}

char* func2()
{
char szBuf[100];

szBuf[0] = 'A'; // assign some value

return szBuf;

}

void func3(char* pBuf)
{
int local1;

local1 = 123;   // corrupt the value in pBuf since it occupies the same memory in the stack

// do more stuff and crash

}

The friendly name comes out of the INF. It’s based on the device class, IIRC, so it’s not unique on a per device basis at all. It’s a category name. There are SetupDiXxx functions that’ll allow you to retrieve it, though I can’t remember if you can easily go from the embedded Device Object name to the Friendly Name.

Peter

How about IoGetDeviceProperty for DevicePropertyDeviceDescription?

Why are you bothering with all of this?

We've been through these religious argument for 15 years or more, and frankly I'm tired of it. Whatever your prejudices against C++ are, they are just silly. C++ is a tool, and it is a powerful one at that. It works perfectly well in the kernel, within the well-known limitations. Many of the streaming drivers require it. Bad programmers write bad code in any language. Presumably, you understand that any C# code you write is just calling C++ native routines underneath.

Thanks, Scott!!!
This code helped:

```
//
DeviceAttribute.DefaultSDDLString = &SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX;

// Register the filter driver
Status = NdisRegisterDeviceEx(g_FilterDriverHandle, &DeviceAttribute, &g_NdisDeviceObject, &g_NdisFilterDeviceHandle);
```

You need to use a different protection on your device object.

I've never written an NDIS Filter but it looks like you need to specify an appropriate SDDL string in your NDIS_DEVICE_OBJECT_ATTRIBUTES. If you're not sure what you want for an SDDL string there are some reasonable default values available in wdmsec.h.

There is no I2C device class, so there is no I2C abstraction API

Except in the land of Windows IoT, where (a) I2C is much more likely to be used as Mr. Roberts alludes, and (b) there’s a very complete abstraction available in C# (at least).

Peter

Welcome to the forum, and thanks for taking the time to write such a clear and complete description of what you are trying to accomplish.

Because of your specific use case, you simply would write an ordinary PCI device driver that controls your I2C controller at the bottom edge, and that takes whatever Reads, Writes, and a Ioctls that you wish to define from your user app at the top edge.

There’s no need for you to fit your driver (or your I2C controller) into the Windows SPB framework, because of your use case: Specifically, you do not want or need Windows PnP to enumerate the Client Device that’s attached to your I2C controller, find the “best” driver for it, and load that driver. Rather, you want Windows to match your driver to your PCIe Controller board, and then you’ll provide a generic interface (probably accessed via a nice user-mode DLL) that user apps use to access the various registers on the I2C client device that’s connected to your controller.

So, that’s pretty easy! You get to ignore everything in Windows about I2C because Windows does not get involved in the management of your I2C bus or the device that’s connected to it.

Sounds like a fun project! Good,luck,

Peter

Hi ,

i went through this link [https://www.osr.com/nt-insider/2016-issue1/intro-to-spb-devices-and-drivers/]

I have a i2c slave device connected to PCH [platform controller Hub]/[Integrated Sensor Hub].

requirement: -

I need to access [i2c slave device] from Windows application [windows 10 OS].

Windows application<--windows 10 os-->main intel chip <--OPI--> PCH <--I2C--> i2c client device.

things i need to do:-

in this regard, i have the following questions

[1]. Add node [related to I2C slave details] in the ACPI statically.

[2]. I2C controller is connected to this slave device and each of the 3 I2C controllers already has device driver in windows 10. so there is no new driver needed.

[3] enable I2C through BIOS.

questions: -

[1] i have a i2c slave device connected to PCH and ACPI is correctly populated with correct node details [windows 10 2019H1]

is this example relevant [SPBcx] for my work

https://docs.microsoft.com/en-us/samples/microsoft/windows-driver-samples/skeleton-i2c-sample-driver/

[2] are SPBCx based example only way of accessing I2C slave connected to ISH/PCH, are there any other ready made tools which can access i2c slave [on top of windows 10 OS]?

Thanks