Um, where to start?
First let's review objects and instances.
When you do this:
MainWindow ob = new MainWindow();
You create a brand spanking, unused instance of a new MainWindow. The
new
keyword is a big clue here. This is not the same as the instance that started the timer. It's like cars: if you put your mobile in the glove box of your car, then go out and buy a new vehicle, would you expect to find your mobile in it's glove box? No - it's in your old car, not the new!
So when you then do this:
ob.Stop_time();
The timer you are stopping is in a different instance of MainWindow (in the glovebox of a different car) so stopping the timer does nothing useful - it was never started in the first place!
To do that, you would need to access the actual instance of MainWindow that started the timer and (presumably) created and displayed the Window1.
And that leads us neatly to the second bad idea! What you are trying to do ties the two windows together - if it worked, you couldn't make any changes to MainWindow without considering if it will impact Window1 and vice versa. That's bad. It's bad from a separation of concerns point of view, from an OOPs point of view, from a reusability point of view, and from a general being-able-to-maintain-the-sucker point of view. Don't do it! Never access controls or anything else on another form except via a property, and never assume that the window that created you is of a specific type.
Instead, create an event in Window1 that MainWindow handles, and it stops the timer itself.
That sounds difficult, but it isn't, not really - it actually very, very simple to do.
Have a look here:
Transferring information between two forms, Part 2: Child to Parent[
^] it's WinForms, not WPF, but the technique (and even the code) is the same - you just don't need the property this time.