0

Our company had a new Windows App developed to use to connect to a SQL database. When the app is run outside of the domain environment, it works perfectly. When the computer running it is attached to the domain, the app immediately crashes.

I've found a couple of errors that I think might indicate the problem, but I'm not sure how to interpret them exactly, or what might be impeding the program. I don't believe its an issue with the firewall, as the program works fine when the PC is off the domain. I've combed through every group policy setting, and there doesn't seem to be anything there that could be inhibiting the app's operation either, though it does seem like a likely culprit given the circumstances.

Here are the errors:

Application Log

Faulting application name: WcBc.UWP.exe, version: 1.0.0.0, time stamp: 0x5e1b7efb
Faulting module name: ntdll.dll, version: 10.0.18362.418, time stamp: 0x99ca0526
Exception code: 0xc0000005
Fault offset: 0x000000000001792d
Faulting process id: 0x5e2c
Faulting application start time: 0x01d5cd738a0fa05b
Faulting application path: C:\Program Files\WindowsApps\WcBc_6.0.3.0_x64__x092f3jx59vf4\WcBc.UWP.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: fc0e2bd5-9704-4ad2-b601-b61c8bfd53a7
Faulting package full name: WcBc_6.0.3.0_x64__x092f3jx59vf4
Faulting package-relative application ID: App

Security log 

The Windows Filtering Platform has blocked a packet.

Application Information:
               Process ID:                           24108
               Application Name:              \device\harddiskvolume3\program files\windowsapps\wcbc_6.0.3.0_x64__x092f3jx59vf4\wcbc.uwp.exe

Network Information:
               Direction:                             Outbound
               Source Address:                   10.80.243.64
               Source Port:                         58988
               Destination Address:           10.101.10.18
               Destination Port:                 4118
               Protocol:               6

Filter Information:
               Filter Run-Time ID:              71531
               Layer Name:                         Connect
               Layer Run-Time ID:              48
Frederik
  • 3,359
  • 3
  • 32
  • 46
Bradley Henderson
  • 1

2 Answers2

1

Dev people should be able to tell you where exactly it is failing but I'm going to assume its security of the folder within WindowsApps. Try to run the app with elevated rights and see if that works.

If yes, then I'd say the app isn't correctly developed as users can't usually write into Program Files but can into ProgramData where any application generated data should be saved.

If not, provide them access to your environment so they can test it within your environment and debug or ask them to write a detailed log into a file which will help with analysis.

PS if you can, setup a quick domain with SQL server and test it within default environment. If it works there, it's group policy so work backwards by adding one after another until you find where it breaks.

JurajB
  • 188
  • 1
  • 8
  • Thanks, I've been able to narrow it down a little further. It's being blocked by the Windows Firewall, but the Firewall is disabled for domain users. I tried disabling absolutely everything related to the firewall via group policy, but it's still blocked by "Default Outbound Rule" even though there I created rules specifically to open the necessary ports, and another specifically to allow the program through. I could only get it to run after using a registry edit to completely stop the base filtering engine service. – Bradley Henderson Jan 22 '20 at 11:59
  • Hm, that is unusual. I know that in same cases you need to open outgoing as well as incoming port. Would suggest to disable FW completely and run netstat to see if the in-out ports are the same as you've allowed. – JurajB Jan 23 '20 at 03:04
0

Since you're working to reverse engineer, it looks like you can identify the filter proper using the filter run-time ID.

From the docs [here][1], you should be able to determine the blocking layer via netsh wfp show filters and look for 71531 the filter run time ID (Filter Run-Time ID: 71531

Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the packet.

To find specific Windows Filtering Platform filter by ID you need to execute the following command: netsh wfp show filters. As result of this command filters.xml file will be generated. You need to open this file and find specific substring with required filter ID ()

That should give you a place to start. outside of GPO, there are some other items that may make sense to troubleshoot:

Kerberos & Authentication: Is the SQL server on the domain as well? is it being used by DNS name or IP? SQL account or domain account? Is there a time difference of greater than 5 minutes? (https://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html)

Receiving Side Firewall: You're connecting to a different subnet, is it possible that there is a firewall/route issue that needs to be configured?

best of luck!

Max Humphrey
  • 74
  • 4