First the simple stuff:

1. Standard naming convention for methods in C# is `PascalCase` while you run a mix of `camelCase` and `PascalCase`.

1. Some of you methods have unclear names and/or unclear parameter names for example this:

        void Button(int p1, int p2, char[,] board)

 What is `p1` or `p1` and what should the method do? The names should be descriptive enough to deduce the functionality from the names.

1. These comparisons are weird: `OX(board[1, 0]) == "O"[0]` - `OX` (another unclear name) returns a `char` so you should compare it to one: `OX(board[1, 0]) == 'O'`

---

Now the bigger picture stuff:

The main issue with your solution is that your UI and logic are very tightly coupled which in general is a bad thing as it makes it hard to re-use the current game logic (try making a text console, winforms or web version for that games) and also not very easy to unit test.

One very popular pattern with WPF application developers is the [MVVM (Model-View-ViewModel) pattern][1]. The basic idea is that you have a model which is completely agnostic of the UI and the UI just observes the model and it's changes. IN WPF this is supported by something called [binding][2] where the UI "binds" the controls to the model which alleviates the need to manually push the data from the model to the UI.

It's a big topic so I won't spill out all the details and it would be a fair amount of work to re-work the code according to it but I would encourage you to do so (could make a great series of code reviews here). There are heaps of excellent articles on code project and lots of assisting frameworks around (although you don't need a framework to follow the MVVM pattern).


  [1]: http://en.wikipedia.org/wiki/Model_View_ViewModel
  [2]: http://msdn.microsoft.com/en-us/library/ms752347%28v=vs.110%29.aspx