Share via

"netsh wlan connect" / wlanapi:WlanConnect from within a Windows Service is not working

Jon 21 Reputation points
2021-05-17T10:23:02.65+00:00

Windows 10 pro, all latests updates are installed.

I have some C# code using P/Invoke calls to wlanapi functions such as creating profiles and connecting to the network.

The same behavior is observed using APIs directly or running "netsh wlan connect". It works from terminal/desktop app, but it doesn't work when invoked from within a service.

If I compile this as a desktop application it all works fine, but if I try to run the same code from a windows service, the call to WlanConnect() fails with "ERROR_INVALID_PARAMETER" (with identical arguments as from a desktop counterpart).

WlanSetProfile() works both from a service and a desktop application.

The service runs with the same user, and I've tried with <requestedExecutionLevel level="requireAdministrator" uiAccess="false" /> in the app manifest as well.

I have also tested to start a process from within the windows service running "netsh wlan connect name=<profile>" and the same problem persists.
Netsh works fine if I run it from the terminal, but if I start this process from within a service it fails with: "Connection request failed with error 0x57."

I have read the documentation https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/ but I can't find any limitations invoking this API from a service.

Windows 10 Network
Windows 10 Network
Windows 10: A Microsoft operating system that runs on personal computers and tablets.Network: A group of devices that communicate either wirelessly or via a physical connection.
2,291 questions
Accepted answer
  1. Gary Nebbett 5,721 Reputation points
    2021-05-17T13:08:40.157+00:00

    Hello @Jon ,

    Debugging a program running as a service can be tricky - especially when one suspects that the problem is not in one's own code.

    What I would try first is to use Event Tracing for Windows (ETW), to see how far the connection process gets before it fails and perhaps compare it with a trace of a successful (interactive) run of the same code.

    In this case, the ETW providers that I would include in a "first cut" trace are: 

    Microsoft-Windows-WLAN-AutoConfig  
{637A0F36-DFF5-4B2F-83DD-B106C1C725E2} 0x7FFFFFFF 3 # WLAN Diagnostics Trace  
{6DA4DDCA-0901-4BAE-9AD4-7E6030BAB531} 0x7FFFFFFF 4 # WLAN HC Diagnostics Trace  
{0C5A3172-2248-44FD-B9A6-8389CB1DC56A} 0x7FFFFFFF 3 # WLAN AutoConfig Trace  
{CBE56FBB-D6CB-4C6D-BCA5-1385426707A3} 0x7FFFFFFF 5 # WlanSettings WPP

    You could just paste these five lines in a file (say "prov.lst") and the issue the following command to start a trace:

    logman start noservice -ets -pf prov.lst -o why.etl

    Then reproduce the problem and stop the trace with the command logman stop noservice -ets

    You might need to share the trace data here (via OneDrive, Google Drive, etc. links) to extract the most value from the trace data.

    Gary

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jon 21 Reputation points
    2021-05-19T06:50:59.53+00:00

    Wow,

    Thanks for the quick and knowledgeable response!

    I have managed to get it to work by saving the WLAN profile with "ALL_USERS" (flags=0) instead of only WLAN_PROFILE_USER (WlanSetProfile).

    The call to WlanSetProfile is within the same process as the call to WlanConnect, so I can't figure out why it wouldn't work. But I suspect it could be related to the access the user has when running from a service, perhaps as the same user is logged on to desktop at the same time.

    Before collecting the logs, I manually "forgot" the WLAN profile from the Windows UI.
    Trace files are located here: https://1drv.ms/f/s!AEiCAgbodrZ5igE