.NET Application will run as a Console Application but not as Windows Forms, Debug Works

Question

I have a Windows Application that worked once before on .NET 2.0, and I just wanted to bring it forward to .NET Framework 4. I've done this hundreds of times before without issue.

Long Story Short: After upgrading, I can run the Windows Application (Written in C#) from both Debug and Release Modes. All of My Assemblies are set to build targeting (x86) to make sure that any 32-bit dependencies will run on Windows 7 x64. The strange thing is that when I run the executable from the bin\x86\Debug or Release directories, nothing happens. Literally nothing. The application starts then immediately stops, and there are no error messages, no crashes, no items written to the event log. It just starts and then stops.

The crazy part is if I switch the project output type to "Console Application", then it works to run it from an exe file! (Just have an annoying and ugly console window in the back of the application while it's running).

Has anyone ever heard anything like this before?

Here are the things that I've tried and more information:

• Looked for any mention of errors in the event log
• Tried running as Administrator
• I'm already the computer administrator with Full Access to All directories
• Tried putting MessageBox.Show statements in Main() function
• Tried putting Console.WriteLine statements in Main() function
• Tried making Main functions public.
• Tried starting the application exe by double clicking it and also running it from the command line (console output didn't appear in that case).
• Tried executables compiled for Debug AND Release
• Tried removing the call to start the MainForm.cs, where just the MessageBox code remains.
• Other Windows Forms applications that are pure .NET 4.0 run fine from their executable.
• The .NET Framework 4.0 doesn't appear to be corrupted, however, I haven't tried reinstalling it in its entirety.
• Tried adding a try / catch in the main function to catch and report any errors.
• Windows 7, 64-bit
• Visual Studio 2010
• Windows Updates performed regularly
• C# for all code

Has anyone seen anything like this? I've been working with C# for over 14 years and haven't seen this behavior before.

Edit: Adding Code from Program.cs minus the namespace tags and using statements

static class Program
{
    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        try
        {                
            MessageBox.Show("Start");
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new MainForm());
            MessageBox.Show("End");
        }
        catch (Exception exp)
        {
            ExceptionDisplay.LaunchUnexpected(exp);
        }
    }
}

The ExceptionDisplay class is just a simple windows form that displays and reports the unexpected error. In this case, it doesn't matter whether the try / catch block is present or not. The same behavior happens with the executable.

EDIT: Adding Exit Codes when in debug mode

The thread 'vshost.RunParkingWindow' (0xf70) has exited with code 0 (0x0).
The thread '<No Name>' (0x25c0) has exited with code 0 (0x0).
The program '[13496] MyProgram.vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).

EDIT: Adding PropertyGroup items from .csproj file

<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C5FE7F9D-57BB-4A6F-AD53-43BE99BAB6CF}</ProjectGuid>
<OutputType>WinExe</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>MyNamespace</RootNamespace>
<AssemblyName>MyAssemblyName</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
<OldToolsVersion>3.5</OldToolsVersion>
<TargetFrameworkProfile />
<IsWebBootstrapper>true</IsWebBootstrapper>
<PublishUrl>http://localhost/MyNamespace/</PublishUrl>
<Install>true</Install>
<InstallFrom>Web</InstallFrom>
<UpdateEnabled>true</UpdateEnabled>
<UpdateMode>Foreground</UpdateMode>
<UpdateInterval>7</UpdateInterval>
<UpdateIntervalUnits>Days</UpdateIntervalUnits>
<UpdatePeriodically>false</UpdatePeriodically>
<UpdateRequired>false</UpdateRequired>
<MapFileExtensions>true</MapFileExtensions>
<ApplicationRevision>0</ApplicationRevision>
<ApplicationVersion>1.0.0.%2a</ApplicationVersion>
<UseApplicationTrust>false</UseApplicationTrust>
<BootstrapperEnabled>true</BootstrapperEnabled>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\x86\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>bin\x86\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup>
<ApplicationIcon>security.ico</ApplicationIcon>
</PropertyGroup>
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>company.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
<PropertyGroup>
<StartupObject />
</PropertyGroup>

UPDATE: I tried moving all of the files from one project to another new project, and after I got it to compile, the exe file was working. Then, in preparation for deployment, I did a few things to the project (including signing with strong name, changing the program's icon, etc.) and then the exe stopped working. After narrowing it down to the latest sequence of events that I performed, I toggled each item that I changed recently one at a time, and discovered that the item that's causing the exe not to build was setting a non-default icon.

If I switch the default icon to a .ico file, then it will debug but not run the exe. If I switch the icon back to (Default Icon) under Application >> Resources >> Icon and Manifest, then the exe will run just fine outside of the debugger ??? Does anyone have any idea why changing something as innocuous as the program's default icon would make the EXE not run? I will Google / investigate this further after I realized the part that's causing it not to run.

Answer 1

The answer to this problem ended up being something totally unexpected. The problem lied in the Application's Icon.

After troubleshooting further, I noticed that when I created a new project, added all of the files to the project, and compiled it - the program would run from the EXE file. I kept going with making changes to the project, and then after some final touches (which included changing the application icon, adding a strong name, and other things that I've done on many other applications), I noticed that suddenly the EXE stopped working when double clicking on it.

I finally narrowed it down to the fact that when I had a Default Application Icon (Project Properties >> Application >> Icon), the application worked fine when launching it from an EXE. However, when I changed the icon to the one that I was using, the EXE stopped working.

I've used Application icons before, so I created a test project that did nothing, but where I changed the application icon to this one. Sure enough, when I did that, the EXE of the test program stopped working.

Next, I tried using a different icon than the one that I was using, and that one's EXE worked. So, now I had narrowed it down to a problem with the particular icon that I was using. I noticed that the one that worked had a 16x16 4-bit and 32x32 4-bit image inside of it. I then opened the non-working one. The Non-working one had 48, 32, 24, and 16 pixel icons for each of (4-bit, 8-bit, and 32-bit pallets).

After trying several combinations of removing various images from the icon, I discovered that the 8-bit color pallete icon images were causing the problem! After removing all of the 8-bit images from the icon, the program is now working normally!

So, the moral of the story is: While icons with 8-bit images may work fine for forms and other purposes, they don't work well with .NET applications as an Application Icon

Answer 2

@Matt This look like you have some security policy applied on you machine that is preventing any unknown executeables(when you click individually). This is working fine in Debug because the host process would have been marked as safe for that policy. Try running the .exe on other machine where custom elevated permission policies are not applied or rather contact your IT Administrator.