Coded in PB windows service crashes if using InitNetwork()

[Lunasole]

1. Compile the following code to standalone exe
2. Get Process Hacker and create service from your exe using it, or do it another way
3. Run your service, then stop it by sending "stop" command

Code: Select all

EnableExplicit
; 	IncludeFile "net.pb"


Global ServiceName.s = ProgramParameter()
Global lpServiceStatus.SERVICE_STATUS
Global hServiceStatus

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


Procedure ServiceHandler(fdwControl)
  Select fdwControl
    Case #SERVICE_CONTROL_PAUSE
      lpServiceStatus\dwCurrentState = #SERVICE_PAUSED
    Case #SERVICE_CONTROL_CONTINUE
      lpServiceStatus\dwCurrentState = #SERVICE_RUNNING
    Case #SERVICE_CONTROL_STOP, #SERVICE_CONTROL_SHUTDOWN
      With lpServiceStatus
        \dwCurrentState = #SERVICE_STOP_PENDING
        \dwWin32ExitCode = 0
        \dwServiceSpecificExitCode = 0
        \dwCheckPoint = 0
        \dwWaitHint = 0
      EndWith
      SetServiceStatus_(hServiceStatus, @lpServiceStatus)
      lpServiceStatus\dwCurrentState = #SERVICE_STOPPED
      SetServiceStatus_(hServiceStatus, @lpServiceStatus)
    Case #SERVICE_CONTROL_INTERROGATE
  EndSelect
  SetServiceStatus_(hServiceStatus, @lpServiceStatus)
EndProcedure

Procedure ServiceMain()
  With lpServiceStatus
    \dwServiceType = #SERVICE_WIN32_OWN_PROCESS | #SERVICE_INTERACTIVE_PROCESS
    \dwCurrentState = #SERVICE_START_PENDING
    \dwControlsAccepted = #SERVICE_ACCEPT_STOP | #SERVICE_ACCEPT_SHUTDOWN
    \dwWin32ExitCode = 0
    \dwServiceSpecificExitCode = 0
    \dwCheckPoint = 0
    \dwWaitHint = 0
  EndWith
  hServiceStatus = RegisterServiceCtrlHandler_(ServiceName, @ServiceHandler())

  If hServiceStatus
    SetServiceStatus_(hServiceStatus, @lpServiceStatus)
    lpServiceStatus\dwCurrentState = #SERVICE_RUNNING
    SetServiceStatus_(hServiceStatus, @lpServiceStatus)

	
    While lpServiceStatus\dwCurrentState = #SERVICE_RUNNING
; 		Proxy_tick ()
      Delay(1)
    Wend

    With lpServiceStatus
      \dwCurrentState = #SERVICE_STOP_PENDING
      \dwWin32ExitCode = 0
      \dwServiceSpecificExitCode = 0
      \dwCheckPoint = 0
      \dwWaitHint = 0
    EndWith
    SetServiceStatus_(hServiceStatus, @lpServiceStatus)
    lpServiceStatus\dwCurrentState = #SERVICE_STOPPED
    SetServiceStatus_(hServiceStatus, @lpServiceStatus)
  EndIf
EndProcedure

Procedure ServiceInit()
  Dim lpServiceTable.SERVICE_TABLE_ENTRY(2)
  lpServiceTable(0)\lpServiceName = @ServiceName
  lpServiceTable(0)\lpServiceProc = @ServiceMain()
  lpServiceTable(1)\lpServiceName = #Null
  lpServiceTable(1)\lpServiceProc = #Null
  StartServiceCtrlDispatcher_(@lpServiceTable())
EndProcedure

InitNetwork() ; // comment it and there will be no crash
ServiceInit()

*service sample by JHP and it seems to be written correctly

[Fred]

Just tried with PB x86 and x64 (installed with Process Hacker) and got no crash at end. Can anybody else confirm ?

[Korolev Michael]

Cannot confirm.
Windows 7 x64 SP1
Windows XP x86 SP3

[GoodNPlenty]

Cannot Confirm
Windows 10 Pro x64 Version 1511 Build 10586.104
PureBasic 5.41 LTS x86 and x64
Type: Own Process
Start Type: Demand Start
Error Control: Ignore

[Lunasole]

Just tried and also cannot reproduce on Win7 x64.
Even on clean XP x86 running at VM it won't crash now.

But on my old PC with XP x86 it crashed. It looks to be something specific to OS configuration, will try to get more details

[Lunasole]

At last I've got access to that my old PC again (WinXP SP3 x86, 2 GB RAM DDR1, CPU without SSE2)

I've tried same code with newer PB version (5.42) and it crashed too.
However (and this is strange) when I used Process Monitor to track it's activity, it DOESN'T crash.


So when running with Procmon (or Regmon, but not Filemon, which uses different hooks) active, it all works nice, but when without it, service process raises "the instruction at address 0x00000000 tried to read memory at address 0x00000000" after receives command to shutdown.

This leads to the conclusion that crash happens when (or after) service does something with registry
Here are lists of kernel mode hooks performed by Regmon/Procmon drivers:

Code: Select all

;Regmon
Hooked by: C:\WINDOWS\system32\Drivers\REGSYS701.SYS
Hooked service: NtClose Actual Address 0xB812BBF8 
Hooked service: NtCreateKey Actual Address 0xB812BA56 
Hooked service: NtDeleteKey Actual Address 0xB812BD77 
Hooked service: NtDeleteValueKey Actual Address 0xB812BE19 
Hooked service: NtEnumerateKey Actual Address 0xB812C0A9 
Hooked service: NtEnumerateValueKey Actual Address 0xB812C359 
Hooked service: NtFlushKey Actual Address 0xB812BCCE 
Hooked service: NtLoadKey Actual Address 0xB812C602 
Hooked service: NtOpenKey Actual Address 0xB812B8A2 
Hooked service: NtQueryKey Actual Address 0xB812C183 
Hooked service: NtQueryValueKey Actual Address 0xB812C477 
Hooked service: NtSetValueKey Actual Address 0xB812BF13 
Hooked service: NtUnloadKey Actual Address 0xB812C7B7 

; Procmon
Hooked by: C:\WINDOWS\system32\Drivers\PROCMON20.SYS
Hooked service: NtClose Actual Address 0xB8D98442 
Hooked service: NtCreateKey Actual Address 0xB8D98238 
Hooked service: NtDeleteKey Actual Address 0xB8D980F0 
Hooked service: NtDeleteValueKey Actual Address 0xB8D98126 
Hooked service: NtEnumerateKey Actual Address 0xB8D98036 
Hooked service: NtEnumerateValueKey Actual Address 0xB8D97F92 
Hooked service: NtFlushKey Actual Address 0xB8D9808A 
Hooked service: NtLoadKey Actual Address 0xB8D98596 
Hooked service: NtOpenKey Actual Address 0xB8D98404 
Hooked service: NtQueryKey Actual Address 0xB8D97C82 
Hooked service: NtQueryValueKey Actual Address 0xB8D97DAA 
Hooked service: NtSetValueKey Actual Address 0xB8D97ECE 
Hooked service: NtUnloadKey Actual Address 0xB8D986E6 

And here is log of all actions taken by service process after it receives "net stop" command (there are no any registry activity, which is strange because of mentioned registry hooks affected to crashes):


Hope this info can help to find source of such a specific crash, I'd bring something like a dump from debugger but not familiar with such stuff

[Fred]

I don't think we can track down this one, it seems very specific.