Can anyone point me to a list of exit codes for the DirectX End-User Runtimes (specifically the June 2010 version, if it matters)? I apologize in advance if this is a simple matter (it should be), but apparently my google skills are sub-par as I have been unable to find them.
For bonus points:
I'm trying to use InstallShield LE to create an installer for a game I am working on. I downloaded the DirectX End-User Redistributable (June 2010). This redistributable has the user install/extract the DX files to a location they specify with the expectation that the user will then manually run the DXSETUP.exe that is extracted to that location. I handle this silently in a custom action with a location that I have specified (with the intent to clean up these files in a later custom action).
From here, I would like to run the DXSETUP.exe from the location that I specified and respond appropriately to any errors that it encounters (display a message to the user that will help them with their specific problem). I'm currently using a C# executable that I have created to run the DXSETUP.exe, which is run from ISLE via a custom action. Since I couldn't find a list of the possible exit codes for DXSETUP.exe, I decided to display a generic message whenever a non-zero (unsuccessful) exit code is encountered which will contain the exit code returned by DXSETUP.exe. Normally, I would call it a day and wait until users start contacting me with error codes, but this setup does not cover a very specific case.
Apparently, if the user cancels the DXSETUP.exe, it returns an exit code of 0, which is supposed to indicate success. I do not know how to detect/deal with this circumstance. As-is, my game's installer will continue to run happily, leaving the user unable to play the game after the installer finishes due to missing DX files.
I apologize if this came out a bit verbose, but hopefully it clearly and adequately explains my situation.
Don't give the user the chance to cancel by running dxsetup.exe with the /silent flag. This is recommended as a best practice by Microsoft.
Related
Using Visual Studio Community 2022 targeting .Net 4.7.2. I create a new C# ASP.Net 4.7.2 web project (NO CORE)
I did not make any changes to the code, project, or solution. I press play after the project creation and the application crashes. The error starts out "Managed Debugging Assistant 'FatalExecutionEngineError'" followed by 'System.ExecutionEngineException'
I came to SO and researched this issue and I have found some decent looking posts. My crash is different. This is not crashing in user code. The first line of the call stack shows the crash happened in external code.
I've tried all the hacks in Component Services to grant permissions. I've tried modifying the registry directly but my company group policy does not allow this.
I've looked in the event viewer and found some interesting information and tried to act on it (read above)
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
and APPID
{15C20B67-12E7-4BB6-92BB-7AFF07997402}
to the user THA\Andy2394 SID (S-1-5-21-117609710-507921405-1801674531-26297) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable).
What is a 'Unavailable SID'? That doesn't seem correct to me. I thought everything had a SID to it. Do I need to check and fix any disk errors?
This local comserver executable is called RuntimeBroker.exe.
I can only suspect that code in RuntimeBroker.exe or code that it raises before entering my code is considered dangerous to the CLR.
This problem is driving me batty and it is preventing me from doing my job. Aside from reimaging machine and starting over hoping it is something microsoft related and related to order of operation on installation, I need some direction please.
Though I am calling this "an answer", it is not satisfying at all. My organization uses Cylance. Since I am an admin in our organization, I removed my machine from its list of machines to protect. That solved the problem.
Others have mentioned Cylance so they deserve most of the credit for this answer that is not an answer.
!!!I would not recommend this!!!
Update: The previous answer is not complete. Sorry. I have been dealing with this for 2 days and didn't capture all my info.
In order to continue with my answer that I don't recommend, you need to boot into safe mode.
Then add a DWORD32 to HKEY_LOCAL_MACHINE\SOFTWARE\Cylance\Desktop called "SelfProtectionLevel" and set the value to 1.
Reboot
You now should be able to stop the Cylance service and uninstall it and find a better A/V that works for engineers.
Sorry that this whole adventure put a sour taste in my mouth and a rankerous oder in my nose.
I guess I understand that software development by nature would be considered dangerous to AV software. Where's a video of McAffee breaking the law. I need a laugh.
Working with Monodevelop has been a nightmare overall. But among all the crashes, I have been able to recreate one of them reliably.
It seems like when I type "o" (the letter) when Monodevelop expects me to type an integer it will always crash.
Examples:
if (spriteRenderers.Length == o <----*CRASH*
for (int i=o <----*CRASH*
Now, of course, this typically only happens when I've made a mistake, but it does seem to be causing the crash.
And by "crash" I mean that Monodevelop stops working, and I get an error message from Windows asking if I would like to force quit the application. Upon re-opening Monodevelop it shows a blank white screen (every time).
The only fix I've found for the white screen is to delete the "Assembly-CSharp..." files in the project folder and then resync the Monodevelop project in Unity3D. I sometimes have to repeat this up to 10 times before Monodevelop will work again, and about half the time I lose a significant amount of work as a result.
Has anyone else experienced something similar? Any ideas on how to prevent this type of crash?
PS: It also tends to crash a lot when I'm typing "default" within a switch statement, but not every time like the "o" instance above.
If typing a specific letter crashes monodevelop there's certainly something going totally wrong here. First, confirm whether typing 'o' crashes monodevelop anywhere in any situation. Because I find it hard to believe that it crashes only when you type o where 0 is expected - because how would monodevelop know what is "expected" in a given situation? So unless that is confirmed, I assume this is not what is actually going on but rather something that you've came to conclude due to confirmation bias (ie it happend two or three times by chance in a situation where you intended to type 0 rather than o).
That said, check if any keyboard shortcut has been assigned to the letter o. You may want to reset keyboard shortcuts to their default. In general you may want to reset all preferences just to ensure monodevelop is using safe defaults for everything. Also check any plugin you may have installed, and disable them if only for testing.
You should also try shutting down Unity, and only run monodevelop. Then create a standalone project in monodevelop (ie C# windows app) to see if the problem also appears in "regular app development mode".
Lastly, upgrade Unity. If you are already on 4.6, get the latest "patch release" from the download page. This might also give you an updated monodevelop.
If all of that does not help, you may want to try Xamarin - the latest version of monodevelop. You can integrate that with unity by installing its Unity plugins, but currently it will not allow you to debug with Unity. In any case it installs itself side-by-side, so you should at least try that to see whether that has a similar problem.
If all of that fails, consider that the problem may be with your system. For instance a tool might have set a global keyboard shortcut on the letter o. A virus scanner or system driver may somehow interfere. Or the whole system is just whacky, perhaps a trojan, a hardware failure, and so on. That is all rather speculative, so at this point it's a matter of trial and error.
I am making program to automate software installation in C#.
I hooked mouse & keyboard to listen events performed while setup installs..
First Admin needs to install program which need to be mass installed on connected clients.
So admin runs Server which hooks mouse & keyboard events while perticular installation of software & admin selects unique screen region for screenshot to later matched on client installation process to determine whether specific form has arrived, only then simulate key or click else wait until screenshot matches..(eg.next form came after clicking on Next Button only then simulate click or Keystrokes)
Correct me if i am wrong..plz..
1) Well i know same thing can be possible with Group policy object but it can only install msi packages not the exe setups... so they need to be converted to msi first.. i googed free programs for this conversion but none are free. ( All free programs are just simple exe to msi converters but that converted msi still ask clients something while installing if any error condition is there) & ofcource u need to purchase windows Server licence for domain controller pc's this will not possible for Indian Schools,Cybercafe's,Charitable Trusts..
2) There is no free program to do this task perfectly AutoIT,AutoHotkey tries it well but not every time it succeeds.
3) White Framework on Codeplex is nice but still hangouts sometimes while installing..
So this way is ok? or there is any other way to do this ( i want to automate exe,msi ondemand unattended installation)
Pertaining to #2, you are indeed incorrect. AutoIt is perfectly capable of handling this, in fact one of the basic AutoIt examples is an Installer (tutorial here: http://www.autoitscript.com/forum/topic/82288-installer-creator/)
With a bit of tweaking you could turn that into a great installer, with much less effort than it would take in C#
Maybe if you could tell us exactly what problems AutoIt has been causing you?
I'm calling vlc from a C# app in order to play a video. I need a way to consistently check if VLC is installed. I've tried checking registry keys, but they don't seem to be consistent or reliable depending on your Windows version or architecture. Anyone have any suggestions/advice?
I'd say you're doing unnecessary work in trying to detect this. What are you going to do if VLC is not installed? Show an error message? Then just try to launch it, and show an error message if it fails to launch. That way, you also capture the case where it is installed, but still fails to launch for whatever reason. Both are error conditions for your program.
Beyond that, make sure that you include a setup program with your application that automatically installs VLC, since your application requires it to work properly. Then, the only situation where it wouldn't be installed (and thus your application would have to show an error message) is if the user explicitly removes it after installation. Since they would have to do so intentionally, it's very unlikely they would be surprised when your application subsequently failed to work.
I ended up just checking HKLM\Software\VideoLAN\VLC\ on machines I could find it and giving the user an option in the settings to specify the path to VLC manually if it wasn't detected from that registry value.
I just try to figure out a good solution on designing the update process for a windows form application i created. I think of a button inside the app for manual checking of an update and checking when starting the app. Only I'm not familiar with technics. I though to have the update setup file in a FTP Server and checking the server for an update with a txt file in there with filename and version info. When app is finished downloading the update, closing and starting the update setup file.
Any suggestions, opinions on the subject?
Application updates these days are one of those necessary evils. Thinking of applications that update automatically, I tend to group them into two categories:
Clean updating, once a month or less often, a speedy update without a lot of nagging or clicking. And definitely no sneaky software included like toolbars and desktop search programs... Firefox tends to be "nice" about updates, though its addons can be naggy.
The other group nags constantly, requires a lot of button clicks or that you reboot, takes a long time to 'unpack' (Adobe Acrobat, looking at you), changes settings against your wishes (Java), or is just generally unpleasant.
With those points in mind, design your automatic update to be as user-friendly as possible, and plan on your users sometimes wanting to skip the update (unless it is critical to operation).
At my company we have a small application that requires updates, but also must function in a very time-sensitive environment. To facilitate updates, we have it do the following:
At startup, a text file is checked on an internal URL (this could be an HTTP or FTP call). The version number is compared to the contents of the file.
If the software is up to date, nothing more is done. If not, a dialog is presented informing the user that the application must perform an update. (In our case there is no option to cancel or wait, but I highly recommend it if you can.)
A setup file is downloaded from the same site, and launched via Process.Start command, with some switches to perform an unattended install/update.
The application is launched after installation and the interruption to user is minimal.
Some things you may want to do differently:
If not checking for updates at startup, provide an option to schedule update checking or manually perform an update check from (for example) a Help menu.
If possible allow the user to cancel or delay an update; there's nothing more frustrating than trying to get work done with a popup dialog asking you to perform an update every few minutes.
Make sure you test your install packages or patches before deployment! (Voice of experience!)
Use ClickOnce http://msdn.microsoft.com/en-us/library/t71a733d%28VS.80%29.aspx
http://www.15seconds.com/issue/041229.htm
Kind regards.