Issues Getting Intel XDK to run - hangs on startup - startup

I've checked googles and stacks and cannot find an answer for my issue, so I'm asking here.
I've installed Intel XDK 2 on my system (Win 7 64b Pro) but cannot get it to start up. I've uninstalled and reinstalled.
I have it installed in the default directory \users\\AppData\Intel\XDK (I think that was it) so there shouldn't be an issue with permissions.
It comes up with the "Initializing page" but nothing else. I've left it be for about 1 hour while I worked on something else, but the window never changes and the app doesn't start. If I kill it and reopen it says that it didn't close properly and asks if I want a normal or safe start; I've tried both options.
Anyone have any issue with this?
(and please don't suggest phonegap / cordova... I've tried to install that on Eclipse and Visual Studio and both have failed miserably to simply work, even with the googles assisting me).

Two things to try:
-- Make sure you have a valid hosts file, for some folks this has been a problem getting the XDK to start, for unknown reasons, some systems either are missing their hosts file or have invalid entries which can sometimes cause trouble. On Windows, your hosts file is located here:
\Windows\System32\drivers\etc
-- Uninstall the XDK and then completely remove these two directories from your system:
%AppData%\..\Local\XDK
%AppData%\..\Local\Intel\XDK

Related

Error "LoadLibrary failed with error 126: The module could not be found" when launching Spyder IDE through VPN

Here's what happens:
Using a Macbook Pro, I use the Microsoft Remote Desktop Connection application to connect to my work computer, which is a Windows 10 machine
If I try to launch Spyder on my work computer, I get this error:
Load Library Error
However:
If I am at my work computer (i.e. physically at work instead of logging in remotely), I can launch Spyder successfully
If I leave Spyder open on my work computer, then go home and do a remote log-in to my work computer, I can use Spyder without issue. The problem/error described above arises only if I try to open Spyder through the remote connection.
This error only seems to affect Spyder and I can use all other programs without issue through a remote connection. As a workaround I've been using other IDEs and successfully running scripts, but I strongly prefer Spyder.
What I have tried so far (without success):
The 4 troubleshooting steps posted by Fazil M. to this Microsoft thread
Uninstalling/reinstalling Spyder using Conda
Restarting my work computer
System Information:
Work Computer OS: Windows 10, 64-bit
OS of computer through which I'm logging in to work computer: Mac OS X El Capitan 10.11.6
Spyder version: 4.1.1
Any thoughts as to what could be going on?
Update--More information and trials:
I checked out Issue #3736 on Spyder's GitHub. It says to download and add a file called opengl32sw.dll to the folder ~\Lib\site-packages\PyQt5\Qt\bin. But when I go to the PyQt5 folder, I do not see a subfolder for Qt. I tried placing it into the PyQt5 main folder, but that did not fix the problem.
I've heard this can be a graphics card issue too. On my machine I have two graphics cards: AMD RadeonT R5 430 and Intel(R) HD Graphics 630.
Darren's answer did not work for me. What did work was to:
First option: go into the device manager and disable the Intel HD Graphics card under "display adapters."
Second option:
run "Gpedit.msc"
navigate to Computer Configuration->Administrative
Templates->Windows Components->Remote Desktop Services->Remote
Desktop Session Host->Remote Session Environment
Disable "use WDDM graphics display driver for remote desktop
connections"
Restart the computer
See https://answers.microsoft.com/en-us/windows/forum/all/windows-10-1903-may-update-black-screen-with/23c8a740-0c79-4042-851e-9d98d0efb539
It took help from my organization's IT contractor, but I fixed the issue by doing the following:
Run a file called "gpedit.msc", which will open up a window for Local Group Policy Editor
In the tree menu on the left, navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment, and open the Remote Session Environment folder (not the subfolder within it)
Make sure the following are set to "Enabled":
"Use hardware graphics adapters for all Remote Desktop Services"
"Prioritize H.265/AVC444 graphics mode for Remote Desktop Connections"
"Configure H.264/AVC hardware encoding for Remote Desktop Connections"
Then restart the computer.
Since I was unable to get pass LoadLibrary 126 error using the solutions provided online and on here, I stepped back and realized the obvious workaround. The errors occurs when you open the program while you're using a remote session, right? The obvious solution is to launch the program while a remote session is not in progress. To do this while you're remoting, you should create a batch script to launch the program but make sure to include to a time delay before that (I used 'timeout 10 /nobreak' to do so). Run the batch script and, before your program launchs, disconnect from RDP. After enough time passes for the program to launch, you can reconnect to RDP and your program will be up and ready

OAuth error when attempting to start-host for chrome-remote-desktop on GCE

I'm running CentOS 7 in a Google Compute Engine VM, and trying to connect to it via Chrome Remote Desktop. When I run the start-host command, it fails with "OAuth error" and no more information.
I accessed the https://remotedesktop.google.com/headless site with Chrome, filled out the choices, and went through the authorization phase. There was not an option for CentOS, so I chose "Debian" and when it gave me the connect command, I replaced the path to start-host with the CentOS one of /usr/lib64/chrome-remote-desktop/start-host, and running the resulting command fails.
I did the likely web searches and found some fairly old and unhelpful information, but nothing useful.
If I can't get Chrome Remote Desktop working, I'd be willing to try another method to run GUI-based applications (in this case, IBM's oneWEX). I can get X11 to sort-of work remotely, but not well enough to run oneWEX.
This is the command I got from the Chrome site, modified to work with CentOS:
DISPLAY= /usr/lib64/chrome-remote-desktop/start-host --code="<code>" --redirect-url="https://remotedesktop.google.com/_/oauthredirect" --name=
The start-host command asked the expected questions of the computer name and PIN, then gave the error:
Couldn't start host: OAuth error.
When you get the code from https://remotedesktop.google.com/headless it is only good for a few minutes, and only one time use.
Just go back to https://remotedesktop.google.com/headless follow the prompts and get a new code for every attempt.
In my case, I got another error when I first ran the command. I tried to resolve it, and reran the same command (with the original code). I kept getting the "Couldn't start host: OAuth error." until I figured out I needed to get a new code from https://remotedesktop.google.com/headless for each attempt.
FYI: The error message is not given right away, but after entering the computer name and double entering the pin.
According to https://bugs.chromium.org/p/chromium/issues/detail?id=1039016, this could apparently also happen if the /usr/lib64/chrome-remote-desktop/start-host binary is not one from the "official" DEBian package built and distributed by Google, but one built from source e.g. by yourself or your Linux distribution (such as the chrome-remote-desktop package built by Fedora; https://bugzilla.redhat.com/show_bug.cgi?id=1788448 aims to clarify how to use that one).
What I can see here is that you previously added some libraries to your CentOS instance, I tried replicating the error myself and inside my CentOS 7 instance (from Compute Engine) I don't seem to have any /usr/lib64/chrome-remote-desktop/ folder.
Or is it from your local machine?
I had the same error and found that refreshing the headless page to get a new code string in the command worked.

Air application not packaging for iOS (air sdk 17)

I am posting this question because I stumbled upon the solution, despite not being able to find anything online which helped my specific problem. I am posting the accidental fix as an answer.
Problem: I am using adt.jar via cmd and an ANT script to package the air tablet application. Everything works fine on my workstation, but ipa builds fail on the build machine. The build machine is just a re-purposed workstation with more memory, larger hdd, and runs tomcat/hudson. Both environments are Win7 SP1. By 'everything' I mean apk builds in various configurations, and ipa builds with testing and production provisions files.
Error messages varied a little bit, but here are the common two messages:
Compilation failed while executing : compile-abc
Error #1042: Not an ABC file.
The stack dump was just a bunch of parameters passed into adt -- application specific.
Things I tried based on many internet searches:
Update to latest air 17 beta (17.115) Did not work. I did not expect this to fix my problem, because the PC which successfully builds the ipa does not have this version of the sdk
Hunted down empty case blocks in the code. There were a couple, but again this did not fix the problem. Still works on my machine and not the build machine. I actually made sure the empty blocks existed on the functional environment to disprove this attempt. I am not using "-useLegacyAOT no", so this should not have helped.
Compared all relevant environment vars between the two systems, and matched the ones that were different. This did not fix the issue.
Checked the version of jdk pointed to by JAVA_HOME. Both were already "64-Bit Server VM (build 20.45-b01, mixed mode)" aka: jdk-6u45-windows-x64.exe
Out of desperation, I ran Windows Update on the environment which failed to produce ipa files. There was a recommended update to the .NET framework which something in my tool chain must depend on. This fixed the problem.
Microsoft .NET Framework 4.5.2 for Windows 7 x64-based Systems (KB2901983)
My personal workstation is always up to date, and I restart often. This was not the case for the build workstation.
EDIT: A second update was also installed at the same time. This could be what fixed things, but I'm not going to question it.
Update for Windows 7 for x64-based Systems (KB3021917)

Wireshark Disscetor Error on Windows Platform

I am trying to build a dissector for Wireshark on Windows platform. But, I am getting an error.
I followed this link to install Wireshark from the source on windows, and I was able to build and run the software successfully.
Then using the README.plugins, I added a plugin, and did all the changes, mentioned in the file.
With the plugin, it built successfully, but whenever I tried running it, a dialog box appears stating The plugin 'ABC.dll' has neither a register routine, a register_tap_listener or a register_wtap_module or a register_codec_module routine.. Though wireshark is running fine, but my plugin is not included in it.
Linux Environment: I tried compiling and running on linux platform, and it worked fine, with the plugin included.Can anybody tell me, where I might be going wrong on the windows platform. Thanks.
There's a bit of magic which happens when building plugins on Windows so that certain symbols in the DLL are declared as exported so they can be found in the DLL at run-time. (I haven't recently dug into all the details, but the mechanism is different on *nix and so the results on each platform might be different).
What version of Wireshark are you building ? (How are you getting the Wireshark sources ?).
The specific error message you re getting suggests you might be building a version of WWireshark 1.10. (The message has changed in the Wireshark development version (1.11)).
In any case, something is not quite right (obviously) as to how the DLL is being built on Windows.
My suggestion as a starting point:
You might be able get an idea as to what's wrong by
comparing the plugin.c file (which is generated at build time) in your plugin directory on Windows with a plugin.c from one of the other Wireshark Windows plugin directories.
The magic occurs in that file.
Things like:
WS_DLL_PUBLIC_NOEXTERN void
plugin_reg_handoff(void)
{
{extern void proto_reg_handoff_unistim (void); proto_reg_handoff_unistim ();}
}

FSharp interactive on CentOS 6.2 with Mono 2.10.2 won't run as non-root

Hopefully this has not been asked/answered before, but I haven't found anything that fits my issue.
I installed mono on CentOS 6.2 as described here using an rpm and then downloaded FSharp-2.0.0.0. I got it all set up and fsi works great (as long as I pass it the option --gui-) while as root. However, when I try to do it as a plain user I get an error telling me something about not being able to access the registry.
Here is a screenshot:
I'm not sure what the issue is (I've never used CentOS before, but a lab I work in does and I want to put FSharp on it for data processing -- thus I have to use CentOS, which I've read can be troublesome with mono). Thanks for any help!
I know little about CentOS, but the error message seems fairly clear, the mono process running fsi.exe does not have access to a file (the file path is given in the message). So it should be just a matter of running as root to give yourself access to the file, or better yet granting the current user access to this file via chmod (or similar tool).

Resources