[RESOLVED] WinSock listen() method seems to be blocked only after a reboot

Depends upon what credentials are used from Task Scheduler to start the program. Why are you starting it from Task Manager rather than the more usual ways of starting a program when someone logs on.

This is an old application (developed for Windows XP) that has `requireAdministrator`UAC request in the manifest. If I add it to the Windows run key, it won't start because of that. Thus my Band-Aid fix to run it from the task scheduler. (Note that in the future I am planning to re-write this application as a service. In the meantime I'm looking for a solution to its existing users.)

Here's the XML for the task that does the auto-run at logon:

Code:

---

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Author>myApp</Author>
    <Description>This task was created automatically by 'myApp' software.</Description>
    <URI>\Starts 'myApp' at user logon</URI>
  </RegistrationInfo>
  <Triggers>
    <LogonTrigger id="Trigger_Starts 'myApp' at user logon">
      <Enabled>true</Enabled>
      <UserId>COMPNAME-69AQ\DC</UserId>
    </LogonTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-21-1896232342-928235351-725216945-1001</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Users\DC\Desktop\myApp.exe</Command>
      <Arguments>-auto</Arguments>
    </Exec>
  </Actions>
</Task>

---

I also made a couple of screenshots with ProcExp of my process itself.

Here's when I run the app via Windows Explorer and it can receive incoming TCP packets:

Attachment 34783

here's the privileges and permissions:

Attachment 34785

And here's when it was run from the Task Scheduler and all incoming TCP packets are blocked:

Attachment 34787

here's the privileges and permissions:

Attachment 34789

What's interesting is that there's no difference in them, except the parent process that starts my app: either `svchost.exe` or `explorer.exe`


Another interesting fact is that the app may sometimes work after a reboot. Like this time, it took me 3 reboots to make it not work. So it sounds like some sort of race condition, but where? Do I need to wait for some library to load before I can call WinSock methods?

OK. A follow up. Please disregard what I said above... I got it solved.

It was a race condition in my app. It was reading the port number into a local cache variable after the thread that uses that variable was started, thus creating a race condition.

Thanks everyone who pitched in!

PS. I was able to verify it by using this tool.