java.lang.UnsatisfiedLinkError: Can't load IA 32-bit .dll - java-8

Hi I am getting this error:
Error loading win32com: java.lang.UnsatisfiedLinkError: C:\Program
Files\Java\jre1.8.0_60\bin\win32com.dll: Can't load IA 32-bit .dll on
a AMD 64-bit platform
while running this program:
public static void main(String args[]) {
Enumeration ports = CommPortIdentifier.getPortIdentifiers();
System.out.println(ports.hasMoreElements());
while (ports.hasMoreElements()) {
CommPortIdentifier port = (CommPortIdentifier) ports.nextElement();
String type;
switch (port.getPortType()) {
case CommPortIdentifier.PORT_PARALLEL:
type = "Parallel";
break;
case CommPortIdentifier.PORT_SERIAL:
type = "Serial";
break;
default: /// Shouldn't happen
type = "Unknown";
break;
}
System.out.println(port.getName() + ": " + type);
}
// System.out.println(port.getName());
}
I am using java 1.8
Thanks in advance

You are probably running a 64 bit JVM.
First, check your JVM by entering this on cmd line:
java -version
If it says "64 bit", you're running 64 bit JVM incapable of loading 32 bit .dll's.
You can use a 32 bit JVM instead.

Related

Windows exception about amdvlk64.dll when trying to create a vulkan instance

I tried using vulkan, but I can't get it to work. When I try running the first sample given (compiled with VS 2019) with the SDK (01-init_instance.cpp) I get this exception when creating the Vulkan instance:
Exception thrown at 0x00007FFFE7EDAD11 (amdvlk64.dll) in game.exe: 0xC0000005:
Access violation reading location 0xFFFFFFFFFFFFFFFF.
I've tried it with app_info.apiVersion set to VK_API_VERSION_1_0 and VK_API_VERSION_1_1. Also tried setting inst_info.pApplicationInfo to NULL but I don't get any change in the behavior.
I am using an amd gpu AMD Radeon (TM) R9 390 Series, driver version is 17.1.1 and there are some other values about vulkan which are Vulkan™ Driver Version 1.5.0 and Vulkan™ API Version 1.0.39 (all picked from the amd driver interface)
And here is the sample:
#include <iostream>
#include <cstdlib>
#include <util_init.hpp>
#define APP_SHORT_NAME "vulkansamples_instance"
int main(int, char *[]) {
VkApplicationInfo app_info = {};
app_info.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
app_info.pNext = NULL;
app_info.pApplicationName = APP_SHORT_NAME;
app_info.applicationVersion = 1;
app_info.pEngineName = APP_SHORT_NAME;
app_info.engineVersion = 1;
app_info.apiVersion = VK_API_VERSION_1_0;
VkInstanceCreateInfo inst_info = {};
inst_info.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
inst_info.pNext = NULL;
inst_info.flags = 0;
inst_info.pApplicationInfo = &app_info;
inst_info.enabledExtensionCount = 0;
inst_info.ppEnabledExtensionNames = NULL;
inst_info.enabledLayerCount = 0;
inst_info.ppEnabledLayerNames = NULL;
VkInstance inst;
VkResult res;
res = vkCreateInstance(&inst_info, NULL, &inst);
if (res == VK_ERROR_INCOMPATIBLE_DRIVER) {
std::cout << "cannot find a compatible Vulkan ICD\n";
exit(-1);
} else if (res) {
std::cout << "unknown error\n";
exit(-1);
}
vkDestroyInstance(inst, NULL);
return 0;
}
Hopefully someone can help as apparently no one on the internet seems to understand why this happens.
Driver version 17.1.1 is very old (IIRC it means Jan 2017). In ideal world it should work, but as you experience there might be some compatibility issues.
Current drivers are at AMD Support site. They offer "recommended", or more current "optional" driver. Never had any problems with "optional", but it may nag to update more often.

Linux kernel on_each_cpu run on only one cpu (cpu0)

I have this:
static void per_cpu_print(void *info)
{
printk("cccpuID = %d\n", smp_processor_id());
}
static void test(void)
{
on_each_cpu(per_cpu_print, NULL, 1);
}
test runs before rest_init in the kernel boot sequence.
I only see one print: cccpuID = 0
Im running ubuntu 16 with the 4.15 kernel inside VMware Workstation and I gave it 4 cores, haven changed anything in the kernel regarding smp.

Unit Testing for x86 LargeAddressAware compatibility

For a win32 executable (x86) we can set the LargeAddressAware flag so it can access a virtual address space of 4 GB (instead of just 2 GB) when running on x64 Windows.
This looks very appealing. However, there are risks involved.
For example see: Drawbacks of using /LARGEADDRESSAWARE for 32 bit Windows executables?
So let's go ahead and configure the system that is executing some unit tests with the system-wide registry switch AllocationPreference set to MEM_TOP_DOWN.
That should do, shouldn't it?
It doesn't!
The problem is that the x86 "test runner" (execution engine) of Visual Studio is not LAA enabled itself.
This parent process will only see the "lower" 2 GB of VAS, and so will our modules to be tested.
Examples from VS2013.1
mstest.exe spawns QTAgent32.exe
vstest.console.exe spawns vstest.executionengine.x86.exe
All of them are not LAA enabled!
So what is the recommended way to use a x86 test runner that is LAA enabled?
here's a little code snippet (VS unit test, csharp) to check for LAA execution environment.
unless it succeeds your test environment is not suitable to have your set of unit tests (also) cover the compatibility with LAA:
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace TestCheckEnv32LAA
{
[TestClass]
public class CheckEnv32LAA
{
#region [Native DLL import]
[Flags()]
public enum AllocationType : uint
{
COMMIT = 0x1000,
RESERVE = 0x2000,
RESET = 0x80000,
LARGE_PAGES = 0x20000000,
PHYSICAL = 0x400000,
TOP_DOWN = 0x100000,
WRITE_WATCH = 0x200000
}
[Flags()]
public enum MemoryProtection : uint
{
EXECUTE = 0x10,
EXECUTE_READ = 0x20,
EXECUTE_READWRITE = 0x40,
EXECUTE_WRITECOPY = 0x80,
NOACCESS = 0x01,
READONLY = 0x02,
READWRITE = 0x04,
WRITECOPY = 0x08,
GUARD_Modifierflag = 0x100,
NOCACHE_Modifierflag = 0x200,
WRITECOMBINE_Modifierflag = 0x400
}
[StructLayout(LayoutKind.Sequential)]
struct MEMORYSTATUSEX
{
public uint dwLength;
public uint dwMemoryLoad;
public ulong ullTotalPhys;
public ulong ullAvailPhys;
public ulong ullTotalPageFile;
public ulong ullAvailPageFile;
public ulong ullTotalVirtual;
public ulong ullAvailVirtual;
public ulong ullAvailExtendedVirtual;
}
[DllImport("kernel32.dll")]
extern static void GlobalMemoryStatusEx(ref MEMORYSTATUSEX status);
[DllImport("kernel32.dll", SetLastError = true)]
public static extern UIntPtr VirtualAlloc(UIntPtr lpAddress, UIntPtr dwSize,
AllocationType flAllocationType, MemoryProtection flProtect);
#endregion
public CheckEnv32LAA()
{
}
[TestMethod]
public void CheckEnvironment32LAA()
{
// check for a suitable environment to test modules for compatibility with LargeAddressAware (LAA):
// 1) OS must be x64
// 2) test runner must be x86
// 3) test runner must be LAA enabled itself
// 4) memory allocation (with manual TopDown flag) must happen beyond the 2 GB boundary
// 5) memory allocation (with default settings) must happen beyond the 2 GB boundary
//
// RE 3) this requirement is true for "regular" unit tests (to test DLL modules). it does not apply
// for any tests spawning the application (EXE) to be tested as a separate process.
//
// RE 5) a failure indicates the following registry switch has not been set:
// [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
// "AllocationPreference"=dword:00100000
//
// see:
// https://stackoverflow.com/questions/2288728/
String sParentProcName = Process.GetCurrentProcess().MainModule.FileName;
//CHECK_1
Assert.IsTrue(Environment.Is64BitOperatingSystem, "Test is not executing on x64 OS");
//CHECK_2
Assert.IsFalse(Environment.Is64BitProcess, "Test runner is not x86: " + sParentProcName);
//CHECK_3
MEMORYSTATUSEX tmpStatus = new MEMORYSTATUSEX();
tmpStatus.dwLength = (uint)Marshal.SizeOf(typeof(MEMORYSTATUSEX));
tmpStatus.ullTotalPhys = 0;
GlobalMemoryStatusEx(ref tmpStatus);
ulong uVM = tmpStatus.ullTotalVirtual;
Assert.IsTrue(uVM > 0x80000000, "Test runner is not LAA enabled (max: " + uVM / (1024 * 1024) + "): " + sParentProcName);
Assert.IsTrue(uVM <= 0x100000000, "Test runner is not x86 (max: " + uVM / (1024 * 1024) + "): " + sParentProcName);
//CHECK_4
UIntPtr pMem = UIntPtr.Zero;
ulong uAddress = 0;
pMem = VirtualAlloc(UIntPtr.Zero, (UIntPtr)1024, AllocationType.RESERVE | AllocationType.TOP_DOWN, MemoryProtection.READWRITE);
uAddress = (ulong)pMem;
Assert.IsTrue(uAddress > 0x80000000, "Test runner is not LAA enabled (highest: " + uAddress / (1024 * 1024) + "): " + sParentProcName);
//CHECK_5
pMem = VirtualAlloc(UIntPtr.Zero, (UIntPtr)1024, AllocationType.RESERVE, MemoryProtection.READWRITE);
uAddress = (ulong)pMem;
Assert.IsTrue(uAddress > 0x80000000, "System-wide MEM_TOP_DOWN is not set (allocated at: " + uAddress / (1024 * 1024) + ")");
}
}
}
So far I have only come across suggestions to mess with the Microsoft binaries listed in the question (i.e. use editbin.exe to manually "patch" them). But this has the following disadvantages:
I need to repeat the patching once any future service pack is installed for Visual Studio
I can no longer test in parallel: "regular" x86 and "extended" x86 with LAA
It seems a proper long-term solution would have to be implemented by microsoft?:
http://visualstudio.uservoice.com/forums/196039-microsoft-test-tools/suggestions/5781437

FreeBSD newbus driver loading succesfully but cant create /dev/** file and debugging

I am installing a new newbuf driver on FreeBSD 10.0 . After compiling with make the driver.ko file has been created and than kldload can load successfully. kldload returns 0 and I can see the device at the kldstat output. When attempt to use the driver opening the /dev/** file, the file is not exist.
I think that this /dev/** file should be created by make_dev function which is located in device_attach member method. To test if the kldload reaches this attaching function; when write printf and uprintf to debug the driver, I can not see any output at console nor dmesg output.
But the problem is after writing printf at beginnings (after local variable definitions) of device_identify and device_probe functions, I can't see any output again at console nor dmesg.
My question is that even if the physical driver has problem (not located etc.), should I see the ouput of printf at the device_identify member function which is called by kldload at starting course (I think)?
Do I have a mistake when debugging newbuf driver with printf (I also tried a hello_world device driver and at this driver I can take output of printf at dmesg)?
Mainly how can I test/debug this driver's kldload processes?
Below some parts of my driver code (I think at least I should see MSG1, but I can not see):
struct mydrv_softc
{
device_t dev;
};
static devclass_t mydrv_devclass;
static struct cdevsw mydrv_cdevsw = {
.d_version = D_VERSION,
.d_name = "mydrv",
.d_flags = D_NEEDGIANT,
.d_open = mydrv_open,
.d_close = mydrv_close,
.d_ioctl = mydrv_ioctl,
.d_write = mydrv_write,
.d_read = mydrv_read
};
static void mydrv_identify (driver_t *driver, device_t parent) {
devclass_t dc;
device_t child;
printf("MSG1: The process inside the identfy function.");
dc = devclass_find("mydrv");
if (devclass_get_device(dc, 0) == NULL) {
child = BUS_ADD_CHILD(parent, 0, "mydrv", -1);
}
}
static int mydrv_probe(device_t dev) {
printf("MSG2: The process inside the probe function.");
mydrv_init();
if (device_get_unit(dev) != 0)
return (ENXIO);
device_set_desc(dev, "FreeBSD Device Driver");
return (0);
}
static int mydrv_attach(device_t dev) {
struct mydrv_softc *sc;
device_printf(dev, "MSG3: The process will make attachment.");
sc = (struct mydrv_softc *) device_get_softc(dev);
sc->dev = (device_t)make_dev(&mydrv_cdevsw, 0, UID_ROOT, GID_WHEEL, 0644, "mydrv_drv");
return 0;
}
static int mydrv_detach(device_t dev) {
struct mydrv_softc *sc;
sc = (struct mydrv_softc *) device_get_softc(dev);
destroy_dev((struct cdev*)(sc->dev));
bus_generic_detach(dev);
return 0;
}
static device_method_t mydrv_methods[] = {
DEVMETHOD(device_identify, mydrv_identify),
DEVMETHOD(device_probe, mydrv_probe),
DEVMETHOD(device_attach, mydrv_attach),
DEVMETHOD(device_detach, mydrv_detach),
{ 0, 0 }
};
static driver_t mydrv_driver = {
"mydrv",
mydrv_methods,
sizeof(struct mydrv_softc),
};
DRIVER_MODULE(mydrv, ppbus, mydrv_driver, mydrv_devclass, 0, 0);
If you don't see your printf's output on your console then your device functions will probably not be called. Can you show us your module's code?
Have you used DRIVER_MODULE() or DEV_MODULE()?
What parent bus are you using?
I guess printf works fine, but I prefer to use device_printf as it also prints the device name, and will be easier when looking through logs or dmesg output. Also leave multiple debug prints and check the log files on your system. Most logs for the device drivers are logged in /var/log/messages. But check other log files too.
Are you running your code on a virtual machine? Some device drivers don't show up their device files in /dev if the OS is running on a virtual machine. You should probably run your OS on actual hardware for the device file to show up.
As far as I know, you can't see the output in dmesg if you cannot find the corresponding device file in /dev but you may have luck with logs as I mentioned.
The easiest way to debug is of course using the printf statements. Other than this, you can debug the kernel using gdb running on another system. I am not familiar with the exact process but I know you can do this. Google it.

How can you tell if an app is 64 or 32 bits?

I have searched to find if this has been asked and I have not seen it. There are questions asking if the OS is 64 or 32 bits. This is not the question I am asking.
On a Windows 64 bit OS, how can you tell if an app (program) is 64 or 32 bits?
The code itself does not say and the installation does not say.
I have a 64 bit machine but I know that I have an other program that is a 32 bit loaded and it runs. So my OS does not exclude me from having a 32 bit program.
So, how can I tell?
You can use tool such as PE Viewer to see information about EXE files.
Personally I use Altap Salamander's viewer feature to see the EXE or DLL architecture.
It is Intel x86 for 32-bit EXEs and AMD64 for 64-bit.
You need to analyze PE header.
It is header of any windows executable. To do that read *.exe as binary, take a bytes that are at offsets 0x3C and 0x3D the WORD made of these is offset of PE beginning.
After you have offset, validate if you are right, beginning of PE is PE\0\0 (PE and two NULL symbols), just skip this indication block and read the next two bytes and make another WORD. It indicates target machine, if you want to check for 64-bit it will be one of the these:
0x8664 - x64
0xaa64 - ARMv8 in 64-bit mode
0x0200 - Intel Itanium processor family
NOTE after you read two bytes, to make WORD you may need to flip them.
Also take a look at this question with answers
And also download PE header documentation from Microsoft
I have knocked up a console application utility in C# to check. It's basic but can be expanded upon.
It returns informational text to the console but also uses the exit code to indicate the type just in case you wish to use this in a batch file.
See below
Cheers
Roj
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
namespace ExeType
{
class Program
{
const int st_error = 99;
const int st_unknown = 98;
const int st_unidentified = 97;
const int st_not_PE_image = 96;
const int st_Exec_x86 = 1;
const int st_Exec_x64 = 2;
const int st_offset = 0x3c;
const int st_P = 0x50;
const int st_E = 0x45;
const int st_ind_x86_1 = 0x4c;
const int st_ind_x86_2 = 0x1;
const int st_ind_x64_1 = 0x64;
const int st_ind_x64_2 = 0x86;
static void Main(string[] args)
{
if (args.Length != 1)
{
Console.WriteLine("Please specify a file");
Environment.Exit(st_error);
}
BinaryReader br = new BinaryReader(File.OpenRead(args[0]));
byte[] block = br.ReadBytes(0x1000);
br.Close();
if (block.Length < st_offset+1)
{
Console.WriteLine("Unknown");
Environment.Exit(st_unknown);
}
int offset = (block[st_offset+1] << 8) + block[st_offset];
if (block.Length < offset)
{
Console.WriteLine("Unknown");
Environment.Exit(st_unknown);
}
int indicator1 = block[offset];
int indicator2 = block[offset+1];
if (indicator1 != st_P || indicator2 != st_E)
{
Console.WriteLine("Not a PE format image file");
Environment.Exit(st_not_PE_image);
}
offset += 4;
indicator1 = block[offset];
indicator2 = block[offset + 1];
int retval = st_unidentified;
switch (indicator1)
{
case st_ind_x86_1:
if (indicator2 == st_ind_x86_2)
{
Console.WriteLine("32 bit");
retval = st_Exec_x86;
}
break;
case st_ind_x64_1:
if (indicator2 == st_ind_x64_2)
{
Console.WriteLine("64 bit");
retval = st_Exec_x64;
}
break;
default:
Console.WriteLine("Unidentified");
break;
}
Environment.Exit( retval );
}
}
}

Resources