早上用了一个半小时总算是解决了昨天遗留的问题。
昨天下午快下班时把service传到服务器上做测试，本以为会一切正常(因为在我本机测试一切正常),但还是发生了意外的事情,服务自动停止,因为没有足够的时间去找问题,就放在今天早上解决了,昨晚上回到家还在琢磨,问题最有可能出现在什么地方?操作文件?操作数据库?晚上睡着了还梦到了用鼠标去点击服务的齿轮小图标。
早上刚到公司就根据昨晚理的思路开始找问题的所在，先从操作数据库找起，在操作数据库的容易出错的语句后都加入写日志语句，重新生成exe文件做为服务加载，测试又出错，查看日志文件没有任何信息，推测问题在操作文件这里。
检查操作文件的代码，咦？没错啊，怎么回事呢？
我想起以前因为文件路径也引起过问题，那么是不是文件路径的问题呢？
路径的字符串是 ”file/”+文件名+”.txt”，也就是在执行文件同目录下的file文件夹下建立txt文件，这样在windows应用程序模式下是测试通过的；
呵呵，这里还有一个小插曲，是我不小心把字符串 ”file/”里的 ”/” 字符给删除了，到现在我也不知道怎么把它给删掉了；检查完代码再测…… 通过！
我都没有做好测试通过的准备，呵呵，它怎么就通过呢？它怎么就可以通过呢？为什么呢？
接着找测试通过的原因，首先在file文件夹里查看日志文件，咦，没有文件，那这说明文件不是没有生成，而是生成到其它地方了；
接着先查看了一下文件路径代码，发现文件路径字符串里少了 “/” 字符，这让我很振奋，因为这说明文件成功建立，只是没有建立在file文件夹里；而这个路径使文件建立在运行程序的同一目录，这更说明加载服务后，其运行进程路径和加载前的可执行文件路径是不同的（windows应用程序运行后其运行进程和可执行文件的路径是相同的）。
呵呵，windows服务的运行进程的路径当然应该是在系统盘下了，在C盘查找名称为 ”file文件名.txt”的文件，呵呵，出来了，原来它躲在system32下。
得出结论：windows服务进程的路径在system32下面
今天找问题的过程中让我几乎抓狂，每次检查代码都没有错误，但就是运行不通过，看来程序员必需要有很好的耐心，这句话说的一点都没错。
