You have a series of problems :
- Saving state (including curent execution points),
- detecting shutdown/reboot,
- restarting after shutdown.
I would suggest that actually your are best off ignoring the middle issue, and ensure that your application keeps a minimal amount of internal state - i.e. store all of your data in an external database etc.
Edit : Make sure that you can save your state in small atomic chunks. An application I have written uses a transactional based relational database, and saves state in a set of three tables) - I also have a system which can detect errors after the fact. The advantage of a database is that it has it's own recover mechanism in case of failures.
If you think about what you need to restart, then you can ensure that when your application restarts it is almost exactly the same state. About the only thing you wont be able to do is restart execution at exactly the same line of code, but actually it may be that that is not the issue, and the issue is maintaining continuity of functionality (i.e. apart from timestamps you can't detect an interruption).
Edit : As an example my application reads the database every time it starts up, looking for records not marked as complete - in this way it can resume the functionality, at almost any point.
Restarting is pretty simple, write your code so it can run as a service.
Edit :
The worst case actually isn't a restart/rebot - in these cases all the running processes are asked to shutdown nicely - and you can trap that signal and do something at least (so long as it is quick). The worst case is a power off/crash (due to overheat for instance), then you get no warning and have zero chance of a clean shutdown. In designing your application you need to consider what is the worse thing that can happen.