I wrote a C# application that is running well on my xp development machine.
When my client is running it on different PC, it seems to freeze on both vista and 7 machines.
I would like to know if there is any issue on running dotnet applications on vista/7.
I compiled the application for both framework 2.0 and 3.5 but it didn't help.
The log file neither doesn't help.
Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ?
Thank you in advance for any help.
Pierre.
Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).
For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.
To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.
Check this link for more information: Making apps UAC aware.
As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).
You do not give much information in order for us to help a great deal.
I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.
Ask your client to capture a process dump using Windows Task Manager,
In Task Manager, find the process that hangs.
Right click and capture a memory dump.
Then you can do some analysis on the dump to see why it hangs.
If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com
csharp applications are supposed to run on vista/win7. This is their home:)
Your problem is not the OS. its your application.
Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.
Check for project independencies and make sure you have shipped to your clients everything your project needs.
and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.
Related
Has anybody had any experience of calling AMSI from ASP.NET? I have a web application that allows users to upload files, and we want to perform a virus scan on each file before we save it to the DB and make it downloadable to other users.
I have developed against Windows AMSI, and when running locally (IISExpress from VS) on my machine it works fine (my test case is that it rejects the EICAR test string in a text file).
However, when I build the application and put it onto our test server (running IIS 10) the test file is not being picked up as malware. I get all of the right return codes when initialising the interface, and scanning the file I get a valid result (of not detected).
Anybody got any ideas? I am running Windows 10 locally and the server is 2016. One thing I have noticed is that on the website it states [desktop apps only] next to supported server. Does this just mean no UWP? Or could it mean nothing running as a service either?
https://learn.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-amsiscanbuffer
Cheers,
Andy
I found the problem, after much headache. It appears that out of the box Windows Defender will automatically exclude the IIS process from malware checks. The effect of this is that the scan method doesn't reject malware.
https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-antivirus/configure-server-exclusions-windows-defender-antivirus#opt-out-of-automatic-exclusions
The automatic exclusions can be turned off.
I confirm that turning off automatic exclusions works. On Windows server 2016, using the local group policy editor, this causes AMSI to start working from IIS. On Windows 10, under Virus & threat protection, adding an exclusion for process w3wp.exe causes AMSI to stop working. So the exclusion is the culprit.
To me it is unclear why this is the behaviour. Windows Defender should not interfere with crucial parts of the operating system, at the risk of causing corruption. Having an exclude list of parts not to be scanned is understandable. So given the standard exclude list Defender will not scan the IIS process. However our route is in the opposite direction. In IIS we want to check a user upload for malware. IIS sends the payload to AMSI. AMSI sends the payload to Windows Defender. Defender should scan the payload for malware. Why does it decide: this is a request by IIS, no need to scan the payload, just return that the payload is clean? If anyone can explain this logic I would be very grateful.
We don't want to turn off automatic exclusions. This would put the production systems at risk. Exclusions are there for a reason.
We still want to use AMSI; we like the idea of a vendor agnostic interface to the locally installed virus product. We now consider the following workaround: from IIS launch a commandline exe that in turn talks to AMSI. Send the payload from IIS to the commandline process, probably using an anonymous pipe. The commandline forwards the payload to AMSI which forwards it to Windows Defender. Defender will scan the payload, as the name of the requesting process is that of the commandline and not w3wp.exe or another name in the exclusion list.
Not too happy with this approach, but it should work. We welcome suggestions for improvement.
We have an application that needs get from an Administrator account to another limited account and the other way around. Currently we are setting the auto logon in the registry, then reboot the machine. This takes up to 3 reboots as the machines are EWF enabled. Our customer support just cannot sit around and wait for the remote machines to reboot while there's an angry customer on the phone.
We have a windows service and a ui running on the machines (written in C#). Most of them are windows 7, but some are windows xp and windows 8.
I was wondering if anybody here knows a way to maybe trick windows into thinking it was just rebooted and auto log into an account. Anybody know of anything? I do know there are tricky ways to log into an account automatically from the login screen, but as far as I understand that's going to require writing a module to replace GINA in windows XP, and in windows vista and up, since GINA was replaced with a "Content Provider", writing a Content Provider or something, both of which seem overkill, but a possible future solution. Any ideas?
NOTE: We are not switching between accounts so that the application can run a process under that account, we are switching between accounts so real people have either administrative access or limited access to the computer. Hope that makes it a little more clear
If you have an application that needs to run between other users and an administrator, you should be creating a launcher application. The launcher application should be using Process.Start() to start your application. You can supply ProcessStartInfo arguments to Process.Start() so that you can run the application using different credentials.
Here'some help. For Xp, there's a simple registry key that does it (search google for AutoLogon), for Win7, it's a bit more complex. See this topic:
http://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-turn-on-automatic-logon-in-windows-7/99d4fe75-3f22-499b-85fc-c7a2c4f728af
I think we had something like this running somewhere, but it wasn't my task and the collegue is on vacation this week. Maybe the above link helps, i'll ask him otherwise.
I read some topics here, but I haven't found the solution of my problem.
I wrote application(C#, WPF, EF, sql server compact) that should start at windows startup. I tried to achieve that in two ways:
Add entry to windows register. Unfortunately that wasn't work on Windows 7. I found here that adding a shortcut to Startup folder can solve my problem...
I've added shortcut to my application in Startup folder. Unfortunately again it is not working...
My application is starting with admin permissions because is using external dll's sql server compact. Maybe this is reason? In addition my application is not signed and probably will not be. Also writing a wcf service could be bad idea in my application.
Do you have any suggestions, or solutions for that problem?
It's against windows guidelines ( and enforced by the operating system ) to put a program that requires UAC elevation in the startup process. It's a horrible user experience to be prompted for elevation every time they logon to a computer.
I would factor the wcf / sql into a service and keep the client side UI elevation free.
Reference: Error message when you start a Windows Vista-based computer: "Windows has blocked some startup programs"
The solution for that problem was to make user to install sql server compact on his own computer instead of embeding it in application folder and change permissions for application to asInvoker from admin.
I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks
I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.
Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.
Does anyone know how to get the MS Office 2007 .NET C# Interop libraries to work with Vista?
I have a .NET C# application that I have setup to run as a Windows service. This program will open up a Word or Excel template depending on the situation and modify its contents and then save the document back out. All of this worked great when I was doing it on a Windows Server 2003 or XP machine using Office 2007. When I moved everything to a Server 2008 box, everything quit working. In Excel for example, I get a COM exception telling me that the Excel file cannot be opened when the file is clearly there and I can open it just fine when doing it manually. The windows service is running under the same user account that I log into the machine with and that account is an Administrator.
Does anyone have any idea what to do?
On Vista and Windows Server 2008, services run in something called Session0. Before Vista, regular programs would run in Session0 alongside services.
This means that Session0 has become a desktop-less wasteland where your services can't even access explorer.exe. I'm pretty sure the problem is that Office applications are expecting to be able to access a few components that are normally on the desktop.
Since Excel, Word, etc. are only supported on a desktop-ed session, you only have a few choices:
Set the Desktop checkbox in the LogOn tab of your Service's properties and pray that it appeases the Office gods. (It probably wont.)
After trying 1, go through your code and try and remove/work around anything that causes it to crash.
Use remoting/WCF to make a server that performs the interop work, and make your service communicate with it.
You'll need to have a logged in interactive user and the user needs to start the server application somehow. Perhaps best to use autostart.
You can try turning on Automatic login. http://support.microsoft.com/kb/324737
Try impersonating a Logged in user using CreateProcessAsUser and friends.
Note: I don't know how well this works unless a user is actually logged in, so it might not be any more useful than 2 above, and is much harder to pull off. (Needs P/Invoke)
Rewrite your program to use the OpenXML sdk or use something like SpreadsheetGear.
You should really avoiding running the Office clients as server side apps. Consider using xml as file format (xlsx for Office 2007, or using the Excel workbook xsd for (somewhat) older versions.) Then you would be freed from using the Excel API on the server.
I did find an interesting article from Microsoft basically saying don't do Office automation.
Get the installables from
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en
install it on your system and refer excel dll in your solution and hopefully it should work.
Do you have the primary interop assemblies installed on the server? These are usually located in the GAC and not included in the bin directory when you build your program, so they would need to be installed locally on the server.
This is just a guess, but it might be UAC. I know that privileged (admin) applications and user applications cannot send messages to each other or communicate in any way. Your service is running as an administrator, but your desktop is running as a regular user under UAC even though they are the same user. I also expect that Office has started up (pre-loaded) parts of itself on startup and that would be running as a regular user.
Try turning off UAC and see if that helps. If so, at least you know what it is.
Do you leave an account logged on to the machine? Office is not a server-side app, and you will get random errors if you try to launch any of the executables without a desktop context.
Something to remember about Office. Its x86 only, so if your creating an application in x64, you will not be able to access the Office underlying COM objects. You will need to compile your application in x86, then it would work.
You can do that by going into the properties of your project, and selecting x86 under the build tab in visual studio.
This is all assuming that your app is being developed/run in a x64 enviroment that is.