The most useful way I've found to understand the Single Responsibility Principle is to interpret "responsibility" as "reason why the code might change". This is because the primary goal of SRP is to group together code that will change together, and (as far as possible) keep code that will change for different reasons separated from it. By doing this, we make it easier to make those changes if they're ever required.
In your case, the only reason you'd need to change your code is if the underlying system code that you're calling via p/invoke changes (either because a new version of Windows changes API in future, or if you decide to port your project to a different operating system).
From this point of view, your code is fine, although it may be worth (if you can ever foresee the possibility of an OS change) grouping this code together with any other system-dependent code, either in a subdirectory or in a library project.
The one change I would make is to encapsulate your return values in something more meaningful than a generic uint - as it stands, your clients need to understand the underlying Win32 implementation, which is a violation of the Law of Demeter. Create a specific return type that encapsulates the value returned by Windows.