Error in Windows 10 LTSC x64

[gocict]

I run Windivert on Windows 10 x64 and it has this error

Is this a bug?

[basil00]

The error is FWP_E_ALREADY_EXISTS which means An object with that GUID or LUID already exists.

I am not sure the cause so you will need to supply more information.

[gocict]

Excuse me, what information i can supply?

[basil00]

Preferably a step-by-step guide on how to reproduce the error, including what program/code you used. Whether the error occurs with the example programs. Whether the error is repeatable or once off. Whether the error goes away after reboot. Anything else you think of.

All you posted is an error code and an OS. If I cannot reproduce the problem it'd be unlikely that it will be fixed.

[gocict]

Sorry for the late reply! I use CitadelCore of TechnikEmpire. It works very well, but on a machine running Windows 10 LTSC x64, it has that error.

[basil00]

Unfortunately there is still not much information to go on. Perhaps @TechnikEmpire has some insight.

Does the problem persist for the WinDivert sample programs, e.g., netdump.exe, streamdump.exe, etc. included in the WinDivert 2.0.0-rc release?

[TechnikEmpire]

I think the windivert version probably most relevant. All citadecore.windows does is open a pretty straight forward diversion handle.

I wonder if the GUID is one of the unique identifiers for windivert layers/sublayers/filters.

Anyway I don't know what more I could add here. Citadelcore.windows is moved to closed development now and I'm in the process of plugging in a custom written wfp callout driver where I stuff all of my app logic into kernel space.

[basil00]

I wonder if the GUID is one of the unique identifiers for windivert layers/sublayers/filters.

Yes, it must be, although I've never seen this error before nor can see how it could occur. What version of WinDivert does the public version of CitadelCore use?

plugging in a custom written wfp callout driver where I stuff all of my app logic into kernel space.

It will be interesting to see what the performance gain is over WinDivert.

[TechnikEmpire]

Windivert I think answers a much broader and dynamic range of requirements than I need is all. I only swap packets to be inbound, so fortunately I don't need be as masterful with wfp as you to get my simple job done. Haha

Windivert has been great to develop against and again thanks for making and publishing it.

[TechnikEmpire]

Public version uses 1.4.x not 2.x.

[basil00]

I only swap packets to be inbound

For this the ALE_CONNECT_REDIRECT layer might be useful, although I've not tried it yet.

[TechnikEmpire]

Yeah but I still need to do dynamic inspection of all packets to catch things like socks proxies and tunnels so I'm basically just copying and pasting citadelcore's diverter logic. AFAIK the ale redirect just targets specific static conditions but I could be wrong.

[TechnikEmpire]

Anyway on topic of the ticket I would make sure the OP hasn't manually upgraded to windivert 2.x and doesn't somehow have simultaneous versions of windivert or conflicting versions, then lastly I'd make sure that version of windows has all the proper subsystems to even run such a driver.

[gocict]

Yes, i'm using Windivert 1.4

[TechnikEmpire]

This is a mystery indeed. I don't think its anything to do with citadel. Citadel just asks windivert to give it outbound packets and then redirects them to itself, as it's a thin proxy around a Microsoft web server.

I would do what basil said and run windivert 2.0's passthru example.

I would go even further and run 1.4's passthru as well. Report both results back here.

On the exact same machine please. Also what are machine specs.

[basil00]

Funnily enough I also got this error after calling TerminateProcess on Tallow. The error occurred when Tallow was relaunched, but the error when away after Tallow was launched a second time. I have not been able to repeat since, so am not sure of the underlying cause.