5

I have an app that I wrote using C# .NET 4.0 in Visual Studio 2010 on my Windows 7 Ultimate machine. This app works fine on both Vista and other Windows 7 computers, but whenever someone running Windows XP tries to run it it crashes.

In order to reproduce this I've tried running it on my Win XP VMWare machine and it crashes for me in there. Unfortunately it doesn't give me any specific error, just informing me that the program has crashed and needs to close.

One other user sent me the following:

Run-time error '339'
Component 'vbalSGrid6.ocx' or one of its dependencies not correctly registered: a file is  missing or invalid.

Code 0xe0434352
Flags 0x00000001

I don't get that particular bit when I try to run it on my Virtual XP machine, and I also made sure to install .NET 4.0 on there.

What could be causing this, and why won't the app run in XP if the .NET 4 framework is supported for XP?

Components used in the program: DataGridView, ComboBox, Buttons, Labels, LinkLabel, NewtonSoft's JSON parser, and that's about it.

I am baffled and have utterly no idea where to start. Ideas?

UPDATE: Hmm, tried running my other recently created application on XP and it loaded fine. The only major difference (in the components I used anyway) between the two is my use of NewtonSoft's JSON library, which I actually think is a .NET 3.5 component.

UPDATE 2: Just for kicks I tried running the program on my Wind7 machine in "Windows XP SP3" compatibility mode and it ran fine. Of course, I have no idea just how closely the "compatibility mode" emulates a true XP SP3 environment, but I figured I'd give ya'll the info anyway.

Sootah
  • 1,771
  • 3
  • 23
  • 42
  • http://stackoverflow.com/questions/4204194/is-net-4-0-compatible-with-windows-xp-sp2-or-below – Mitch Wheat Feb 20 '11 at 02:28
  • are they all 32 bit? it might not be the os as if you are dealing with 64 vs 32 bit??? – John Sobolewski Feb 20 '11 at 02:28
  • you must have WinXP SP3 (or above) – Mitch Wheat Feb 20 '11 at 02:29
  • @Mitch: He said he has .NET 4 installed, I think that wouldn't be possible if he didn't have the prerequisite WinXP SP3. – Ben Voigt Feb 20 '11 at 02:33
  • NewtonSoft's JSON library is not part of the .NET Framework 3.5/4, and .NET FW 3.5/4.0 is not using OCX technology at all, due to the fact that .NET FW 4.0 is COM based – Alan Turing Feb 20 '11 at 02:39
  • @Artur: .NET isn't actually based on COM (ActiveX and OCX and OLE Automation are just more names for COM), but it does have some interop capability. Since NewtonSoft isn't part of .NET, I think he must be installing it alongside his program, or else he'd have failures on Vista and Windows 7 as well. – Ben Voigt Feb 20 '11 at 02:53
  • I have SP3 running on my VM. I know that the NewtonSoft JSON component isn't part of .NET itself, bit I believe that the one I'm using is using .NET 3.5. – Sootah Feb 20 '11 at 03:51
  • Also: Yes, the app is strictly 32 bit. – Sootah Feb 20 '11 at 03:55

3 Answers3

8

¡¡ IT WAS THE APPLICATION ICON !!

I kept noticing that the module it referenced in the error it gave me was system.drawing which I thought was odd. I figured perhaps the PictureBox I was using was causing the issue, so I tried disabling everything to do with that, to no avail.

I had my business partner set up his XP box so that we'd have another machine to test with aside from my VMWare XP box just in case there was some odd issue with it.

After he got it set up and the app copied over he said "The icons look like DOS ones" and I had a eureka moment.

I was using .PNG's as the icons because they support transparencies and whatnot, but XP doens't natively support them. So when the app was copied to the desktop it just used a generic icon for it, and when the application was run it crashed because XP doesn't know how to render a .PNG.

Sootah
  • 1,771
  • 3
  • 23
  • 42
  • 1
    Glad you found the problem. You should mark your own answer as accepted if none of the others helped you solve it. – Ben Voigt Feb 20 '11 at 05:29
  • 1
    I will, but I have to wait another day before I'm allowed to answer my own question. – Sootah Feb 20 '11 at 18:10
2

Try using the Fusion Log Viewer to debug startup errors in .NET applications.

Scott Hanselman has written a nice howto along with links to further resources if you need to go deeper.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

Are we sure this is some wierd .NET compatibility issue or just a run of the mill bad installer/deployment problem?

Here's one user who has that error message because the OCX DLL was copied to System32 with a shortname. Renaming the DLL to the correct name and running RegSvr32 resolved his problem.

Do you have an installer? Have you correctly identified all of your managed and unmanaged dependencies and properly authored them into your installer?

http://forums.elmsoftware.com/forum_posts.asp?TID=119

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • I actually don't have an installer written for it yet. For the moment I'm just sending a .zip of the application to my beta testers. This has worked fine for my previous apps, the current one is the only one that has had any issues with XP. I've beta tested all of my prev ones by just sending a .zip as well. – Sootah Feb 20 '11 at 03:53
  • I suspect that's your problem. I really suggest investing in a Continous Integration / Continous Deployment solution. Think Test Driven Developement..... Setup Driven Development. The moment you add a dependency to 'vbalSGrid6.ocx' you should be thinking 'how do I get that deployed to my customers machines?'. In this case you need to ask 'is it redistributable or do I have a dependency on some one elses software installed?' If you can redistribute it you also have to think 'This is a COM server. It needs to be registered.' – Christopher Painter Feb 20 '11 at 15:42
  • Taking the SDD ( Setup Driven Development ) approach makes sure that you don't build up massive technical debt and panic when you are trying to ship your product. – Christopher Painter Feb 20 '11 at 15:45