The question, as formulated, make little sense, because you did not provide any information on your application.
At the same time, you probably faced some really existing problem and can use some help. I can give you basic ideas on what you can start with. First of all, let's quickly consider the possible issue that is not related to possible incorrectness in your program, so let's consider it first, to close this part of the issue. XP is not supplied with .NET, and Windows 7 is bundled with preinstalled .NET v.3.5. You did not even report which .NET version is your application target. If you targeted it to v.4.0, 4.5 or 4.6, and it wasn't installed on Windows 7, your application should not work. This is a trivial issue, but 1) you should provide exact system requirements in your Release Notes, 2) you really, really need to specify the target version when asking such questions, 3) you may want to distribute required version of .NET with your application (you have a right to do so, .NET framework is freely redistributable).
If this is not a problem, and if your application is really targeted to x-86 32-bit (but I have no idea why; in most cases, the CPU architecture should be "AnyCPU", anyway, you did not specify it in your question), then the conclusion is not very pleasing: you don't really have an application which works correctly even on XP. If so, the sooner you admit it, the better. Any really correct application written for XP should work on Windows 7. But what is "really correct" is somewhat philosophical question. It's very likely, that such application cannot work on XP with some different configuration or even for a different user.
Why it's very likely? Because there is one of the most typical problems: permissions. Before I explain permission considerations, do a simple thing: run the application with
elevated permissions. If it starts working, the problem is really permissions. If not, it still can be permissions. Please see:
https://en.wikipedia.org/wiki/User_Account_Control[
^],
http://4sysops.com/archives/vista%E2%80%99s-uac-8-ways-how-to-elevate-an-application-to-run-it-with-administrator-rights[
^],
http://www.sevenforums.com/tutorials/11841-run-administrator.html[
^].
The typical mistakes are: wrong assumption that some file or directory is accessible or hard-coding of some file paths in your application. There are no cases when hard-coded path names can be useful. In all cases (in production-grade applications, of course), path names should be calculated during runtime based on executable directory or special directories configured per user or "for all users", from user input or some configuration files.
Another problem is exception handling. Even though exception handling should be minimized, you should not leave any unhandled exceptions. To handle them all, you need to handle them all at least on the top stack frame of each thread. Moreover, you should never leave any unhandled exceptions unnoticed. Any abnormal behavior should be reported by displaying comprehensive exception information and/or logging, perhaps optional. Unfortunately, many marketing people try to press on development team to conceal unhandled exceptions and other unsolved problems, but I would call it cheating. If you have no access to the customers' computers, you still accept problem reports from them which helps you to maintain the product.
—SA
Submit an article or tip