To be honest, there is no point at all in trying to "optimise" code that doesn't do what you need it to: it may be the fault that causes it to run slowly, or it will need reoptimizing after the fault is fixed.
So start by making it do what you need it to, which we can't do as we have no access to your data, and that is probably very relevant to the problem.
So, it's going to be up to you.
Fortunately, you have a tool available to you which will help you find out what is going on: the debugger. If you don't know how to use it then a quick Google for "Visual Studio debugger" should give you the info you need.
Put a breakpoint on the first line in the function, and run your code through the debugger. Then look at your code, and at your data and work out what should happen manually. Then single step each line checking that what you expected to happen is exactly what did. When it isn't, that's when you have a problem, and you can back-track (or run it again and look more closely) to find out why.
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!
When you have the code fully working, start by using the
Stopwatch Class (System.Diagnostics) | Microsoft Docs[
^] to find where the code is slow and get an accurate baseline set of measurements to show how much of an improvement (or otherwise) changes make.
Focus on the slow bits, as they will give the biggest "rewards".