I am using Indusoft Web Studio v7.1 (a scada software) that runs on a com port. Everything goes well for half a day or even for a day. But after that it shows an error
error Initializing driver MODBU: Invalid Serial port
although the same serial port is selected in scada and system.
Then, how can I determine the process on a comPort running as I can't find anything in windows process explorer?
Any help will be appreciated.
You could try to enable and disable de COM when you aren't using it. Using a Bool variable.
Driver Sheet
Disable field: Type a tag or an expression to enable and disable the communication of each MAIN DRIVER SHEET on the fly.
Type a value (or expression result) that is greater than zero to disable the MAIN DRIVER SHEET.
Type a zero (or leave this field blank) to enable the MAIN DRIVER SHEET.
Or try to stopt/start your driver runtime, if works you know that the problem is in the Indusoft and not a windows problem.
Tasks
Related
I have an Excel addin, developed in VBA, deployed on the network.
The addin reads from an Oracle database, and pastes tables in a new worksheet, which will also contain a button (triangle shape) to refresh the table.
Everything works great, but I must protect code with password.
When i do, the following error appears on some machines:
Compile error in hidden module: Main.
This error commonly occurs when code is incompatible with the version, platform, or architecture of this application.
Although it compiles perfectly when unlocked.
On other machines it requires VBA password on close, even though i have nothing of the sort defined under close event.
I am hoping to secure my code, without running into above problems.
Any suggestions are appreciated.
I know of two situations in which this error occurs:
1: 32bit vs. 64bit issues (already mentioned in the comments). If you've developed a 32bit addin and try to deploy/use it within a 64bit Excel, then your quoted error message will appear.
2: Missing references.
I think the second option is more likely to be the cause of the problem, because usually all client PCs in a company will have the identical version of MS Office installed and this error occurs only on some machines.
So I suggest to check your references. In the VBA-Editor (Alt+F11) go to tools --> references and note down any ticked modules. Then compare this to a client where the error is occuring (go to client PC and repeat the procedure).
If the ticked modules don't match between development and client PC, this is most likely the cause of this issue. You might also encounter modules with a "MISSING" written in front of their name on the client PC. In this case, remove the tick from the missing module and try to execute your addin.
If it works flawlessly you should be good to go, if not you'll have to manually install the missing modules on the clients PC.
Hope this will help you.
I'm trying to create a piece of software that will not be susceptible to bots. Is there a way for me to code into a program a way to check in the operating system for a process just like it and then put in a shutdown mechanism if it is recognized. Think of something like netflix where if one tab in chrome is running netflix, a second tab being opened will display an "oops" message. Is there anything like this for something that does not run on a web browser? What should I be looking into?
Thanks in advance
There can be plenty of solutions; the first coming into my mind are:
1) your program checks for existence of a particular file; if the files is not found then the program continue, otherwise your programs know that another instance is running and thus can terminate immediately. If the file is not found, your program creates it and then delete it before exting.
2) you can use an operating system call or an o.s. utility program to know if another instance of your program is running (e.g.: in linux, the command ps)
have fun
I develop a few tools in C# using the .Net framework and I am considering the move to Mono. Based on the compatibility analyzer tool (MOMA), the only compatibility issue is the licensing code:
I use Window's serial number and a few other things to generate a computer ID which I then use to generate and manage my licenses.
Obviously, Windows will not be available on Linux or Mac, so I need another way to generate a computer ID.
What can I use in mono to create a reasonably reliable computer ID?
Use a MAC Address:
Get MAC Address in linux using mono
That should be unique to a given network interface, which would uniquely identify the machine.
Also, see this thread discussing the pitfalls and issues related to DRM in mono.
You can use a combination of either CPUID and a hard drive serial number.
As for your code, there is not going to be an elegant way to do this with a one-liner. You will have to check which platform you are running on via Environment.OSVersion. And then based on that, branch your code to do system-specific access. For example, to get CPUID/hdd serial number, use a WMI query; or parse the output of hdparm -I /dev/hda and go from there.
You could use a portion of how Microsoft checked hardware for Windows XP activation. They checked 10 items
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
When XP was (re)installed/activated it'd contact their servers and if 7 or more of the above items were unchanged it would activate without the need to speak with anyone.
I, personally, would recommend against using the MAC address. As you mentioned, it can be easily changed. Additionally, most machines have two or more network cards now (wired and wireless). It gets worse with virtualization as the MAC can be changed even more easily than the physical one can (do you license differently for virtual environments?)
Another option, instead of checking all 10 hardware components, is to use the UUID of the root file system. The downside of this, is that if the drive ever has issues, the license needs to be reacquired.
sudo blkid
/dev/sda1: TYPE="ntfs" UUID="72C0DE8EC0DE57C5" LABEL="windows"
/dev/sda2: UUID="30fcb748-ad1e-4228-af2f-951e8e7b56df" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: TYPE="swap" UUID="8c4e69f8-5074-42c0-8134-0b2429c4c02c"
/dev/sdb1: SEC_TYPE="msdos" UUID="4848-E35A" TYPE="vfat"
After a whole day tracking down a memory leak in my VB.NET project, I have traced the cause to a bug with FileMaker's ODBC driver !
To reproduce you'll need a database you can connect to (I have mine hosted on Server Advanced 11.0.3, but you can also host it locally), and the ODBC driver registered/installed on the PC (I tested versions 11.3 and 12.0, and the latest 12.2).
Start a new VB.NET WinForms project, add a button to the form and paste this code onto the button's click event:
Using cn_FM As New Odbc.OdbcConnection("DRIVER={FileMaker ODBC};SERVER=192.168.1.xxx;UID=admin;PWD=admin;DATABASE=test;")
cn_FM.Open()
End Using
All this code does is open a connection to a FileMaker database, however if you analyse the memory usage in Windows Task Manager you can easily see (by repeatedly clicking the button you just made) that cn_FM is not being disposed properly because the Handles keep increasing! I tried forcing Garbage Collection but this didn't do anything, so I assume its a problem with the driver itself.
Oh, and I tested connecting to a SQL database in the same way, and as you would expect, there was no handle leakage...
Can anyone confirm this is correct?
Edit: I tried various ways of opening and closing the connection, as well as actually querying the database for something in the using block. Also tried hosting the fp7 file locally, but still no go :(
FileMaker's ODBC drivers are horrible and they admit it. You'll also find that your CPU spikes to nearly 100% for every query you hit the FM server with. I've been griping at them about it for years.
Their "solution" was to introduce External SQL Sources, but that requires you to go the other direction. You can bind your VB database to FileMaker and then access the data just like actual FileMaker data. This will allow you to create scripts on the FM server to sync whatever tables you need to sync with your VB database.
It's not ideal, but that's going to be your best bet to get something together with good performance.
I got around this problem by making a persistent connection (declare and open it once and leave it open). But I need to check if its still open each time I want to use it, for example:
Public Sub CheckOpen(ByRef cn As Odbc.OdbcConnection)
If cn.State <> System.Data.ConnectionState.Open Then
cn.Close()
cn.Open()
End If
End Sub
If you have multiple FM database files then this may mean you need to have one connection for each file.
Side Note: FileMaker's xdbc_listener.exe process running on FMSA is also leaky. We have noticed a pattern that once it reaches just under 2GB memory usage it crashes. So keep in mind that the process may need constant restarting.
I'm writing managed code that has to interact with a vendor's COM automation server that runs out of process. I have found that this server becomes unstable if more than one client connects to it. For example, if I have managed code in process A and managed code in process B both connecting to this COM server, a single process will be spun up for the COM server and it's behavior is less than reliable. I'm hoping there's a way to force a separate process for each client - server connection. Ideally, I'd like to end up with:
Managed Process A talking to COM Server in process C1
Managed Process B talking to COM Server in process C2
One thought that came to mind was that if I ran process A and process B with different security identities, that that might cause the COM infrastructure to create separate server processes. I'd rather not go down that road, however. Managed Process A and Managed Process B are actually Windows Services. And I'm running them with identity Local System (because I need them to be able to interact with the desktop, and you can't check the "Interact with Desktop" box on the services applet for services that don't run as Local System). And the reason I need to interact with desktop is that this COM server occasionally throws up a dialog box on the screen and if the service itself cannot interact with the desktop then the COM server is spawns can't display the dialog (I believe it is displayed on a hidden WinStation).
Place the component registered at COM+, this put an isolation layer at your.
Use : Control Panel->Administrative Tools
or cmd/execute DCOMCNFG
Component Services->Computers->My Computer->COM+ Application, right click, new application, next, Create an empty application, enter app name “COM+ your.dll”, next, select Local Service, next, next, next, finish.
In new item made, expand, at Components, right click, new component, next, select Install new component, select your component.
Click Component properties, tab Identity, select System Account.
For errors in calls see Event after.
It's been a while since I've done this, so my memory is hazy.
If you configure the OOP COM server as a DCOM server using the DCOM config tool, I believe you can specify the isolation level. I did this years ago with a non-threadsafe in-process DLL that needed to be accessed in a threadsafe fashion from IIS and it worked a charm.
Let me know if it works for you :)
Your best bet would be to get the vendor to fix the component. After all, if it won't handle multiple clients, there could be other bugs lurking. If you can't do this, there are some other things to try.
With in-process COM objects I've had occassion to manually load the dll and access the interfaces directly without going through COM.
I haven't done this myself with out-of-process COM, but there are some things you could try. Ultimately the library is just a process sitting there receiving messages which invoke functions.
You might be able to manually start the a new copy of the process for each client and then send it messages. You may run into some hiccups with this. For example, the process may check to see if it's already running and refuse to start or otherwise be unhappy.
If you have a known upper limit on the number of clients, another approach you could consider would be to make multiple copies of the original .exe file and then use binary patching (something similar to the detours library from Microsoft Research) to override the COM registration functions and register each copy as a separate COM object.