OMSA Crash

Hello

Did you restart the server after OMSA was uninstalled and again after it was installed? Also, OMSA communicates with the BMC/iDRAC to populate the information. If the iDRAC is not functioning correctly the data will not be populated. The service shouldn't have issues running if the iDRAC is not functional, but if the iDRAC is partially functional and sending corrupt data to the service I guess it could crash it.

I would test the iDRAC by running racadm commands like racadm getsysinfo to verify it is functional.

Thanks

Hallo Daniel,

thanks for your reply.

I have shutdown the server and even disconnected the power for several seconds before booting again. But the OMSA still shows no information.

I just installed OMSA 8.5 and the command line tools again.

The result in the webbrowser is the same. Please see the screenshot for details. Sorry the web interface is again in German, I don't know how to change that. But you see that there is a message saying "Cannot determine Storage controller". This is just an example. I don't see any information ...

But when I run your suggested command I get a reasonable output.

So it seems that iDrac is working. In addition, I can access iDrac via WebInterface.

I have iDrac 6 Express (unfortunately not Enterprise) installed in the R710.

C:\Windows\system32>racadm getsysinfo

RAC Information:
RAC Date/Time = 06/15/2017 16:31:46
Firmware Version = 2.85
Firmware Build = 04
Last Firmware Update = 11/15/2016 20:30:51
Hardware Version = 0.01
MAC Address = d4:ae:52:be:9e:22

Common settings:
Register DNS RAC Name = 0
DNS RAC Name = idrac-
Current DNS Domain =
Domain Name from DHCP = 0

IPv4 settings:
Enabled = 1
Current IP Address = 10.0.0.253
Current IP Gateway = 10.0.0.254
Current IP Netmask = 255.255.255.0
DHCP Enabled = 0
Current DNS Server 1 = 10.0.0.3
Current DNS Server 2 = 10.0.0.254
DNS Servers from DHCP = 0

IPv6 settings:
Enabled = 0
Current IP Address 1 = ::
Current IP Gateway = ::
Autoconfig = 1
Link Local IP Address = ::
Current IP Address 2 = ::
Current IP Address 3 = ::
Current IP Address 4 = ::
Current IP Address 5 = ::
Current IP Address 6 = ::
Current IP Address 7 = ::
Current IP Address 8 = ::
Current IP Address 9 = ::
Current IP Address 10 = ::
Current IP Address 11 = ::
Current IP Address 12 = ::
Current IP Address 13 = ::
Current IP Address 14 = ::
Current IP Address 15 = ::
DNS Servers from DHCPv6 = 0
Current DNS Server 1 = ::
Current DNS Server 2 = ::

System Information:
System Model = PowerEdge R710
System Revision = II
System BIOS Version = 6.4.0
Service Tag =
Express Svc Code =
Host Name = HV01
OS Name =
Power Status = ON

Embedded NIC MAC Addresses:
NIC1 Ethernet = d4:ae:52:be:9e:1a
iSCSI = d4:ae:52:be:9e:1b
NIC2 Ethernet = d4:ae:52:be:9e:1c
iSCSI = d4:ae:52:be:9e:1d
NIC3 Ethernet = d4:ae:52:be:9e:1e
iSCSI = d4:ae:52:be:9e:1f
NIC4 Ethernet = d4:ae:52:be:9e:20
iSCSI = d4:ae:52:be:9e:21

Watchdog Information:
Recovery Action = None
Present countdown value = 451 seconds
Initial countdown value = 480 seconds

I was looking at the compatibility of OMSA to make sure it is validated for server 2016 and I noticed the file name of the version you downloaded. It looks like it might be the web version.

I have updated to the latest version 8.5 A00 (OM-DRAC-Dell-Web-WINX64-8.5.0-2372_A00)

The file name I have for the latest version of OMSA is: OM-SrvAdmin-Dell-Web-WINX64-8.5.0-2372_A00.exe

www.dell.com/support/home/Drivers/DriversDetails?driverId=GYP4R

Uninstall the version you have and install the above version. If the issue persists then run this from command line to verify the OMSA base driver is running. If it is not running then it can cause the services to fault:

sc.exe query dcdbas

Thanks

Hallo Daniel,

sorry for the confusion.

I actually downloaded and installed this file "OM-SrvAdmin-Dell-Web-WINX64-8.5.0-2372_A00.exe".

In addition I've also installed the OM-DRAC-Dell-Web-WINX64-8.5.0-2372_A00 in order to execute the command "racadm getsysinfo", as I showed in my last post.

Here is the result of the execution:

C:\Windows\system32>sc.exe query dcdbas

SERVICE_NAME: dcdbas
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

Seems fine to me.

Regards

If you try to manually start the storage service does it stop automatically and cause the error noted in your previous post?

If the iDRAC is functioning correctly and the OMSA files are not the issue then I would suspect something is conflicting with OMSA. It could be almost anything on your system. I would start by updating drivers and firmware throughout the system. You could also try a selective startup.

Also, if you have any other management applications running I would shut them down to see if that resolves the issue.

Thanks

Yes, the service keeps crashing, after it has been started - no matter if the service starts automatically or manually.

There is not much installed on the HyperV. Basically there are 4 programs running:

• Veeam Backup
• Veeam One
• Ubiquitiy Controller
• OpenManage

I shut down all other applications and still the service keeps crashing.

And it has already worked with exact this configuration. I haven't changed anything on this instance.

Could there any problem with the access of the iDrac?

I noticed that the iDrac is only accessible via LOM1.

I am running also a Sophos XG instance on this HyperV. I have 4 LOMs and I was wondering why iDrac was not accessible via WebInterface. I realized that the wiring was wrong, because LOM1 was connected to the DSL modem. I switch it and iDrac web interface was again accessible. Could this be related to the issue?

Are there any additional logs for the OMSA? I would like too see why it's crashing. I've only found the crash report I've already posted.

Best

Hallo Daniel,

there are not many applications running directly on the HyperV instance. I am using this instance basically for virtualization. So I cannot think of any obvious software changes, but of course I am updating Windows from time to time. Unfortunately I cannot exactly say, when the problem occured for the first time. I noticed it some days ago - unfortunately just after the Windows Update has finished. I am not checking OMSA regularly, but of course when I need it, it's very handy - especially for checking the health of the storage/RAID.

Actually the only thing I've changed in the last half year is the firewall. I was using a Fortigate 80C appliance and switched to a virtualized Sophos XG, as the Fortinet ethernet ports were too slow for the new internet connection. I changed the ISP in early January this year. Previously I teamed up all 4 LOMs to LAN, but now I am using 2 LOMs for WAN (two different ISPs) and 2 LOMs are still teamed to LAN.

I cannot  find any setting for "OS-to-iDRAC-pass-through". I think it should be somewhere in the network settings, but I cannot see anything like that. Please see screenshot.

Thanks for your help

Could you imagine anything that keeps the service from running?

The only things I could think of would be the OMSA base driver, iDRAC, OMSA itself, or something in the OS. I feel fairly confident based on the testing we have done that the OMSA base driver, iDRAC, and OMSA itself are unlikely the problem.

I'm running the same version of OMSA on server 2016 in the lab without issue. Since this issue appears to have started suddenly with no changes to OMSA or the iDRAC I would suspect some software change on the server. Do you recall any operating system or driver updates happening around the time this happened? Any system changes at all?

I haven't run OS updates on the lab server in a long time. I'll try to get the OS up to date and see if I encounter any issues with OMSA.

The external firewall device should not affect OMSA. OMSA does not use the network to gather information. If you have OS-to-iDRAC-pass-through enabled in the iDRAC then that may impact OMSA, but it should still not route beyond the network interface. Do you have that option enabled?

Thanks

I forgot this was an iDRAC6. The passthrough feature was added in iDRAC7, so it is not something you would have configured.

I updated my lab server to the latest Windows updates and I am still not experiencing any issues with OMSA. I'm running the same version of OMSA on the same OS, and I think we are both running the most current OS updates.

At this point I have to assume that this is some obscure compatibility issue, Server 2016 is not a validated OS for the R710. The functionality of the service seems to be intermittent based on the information provided so far. Perhaps you will have better luck with OMSA by not using the shortcut to open it. If you go to a local server address on port 1311 in a supported browser it should open the OMSA web interface. Something like https://127.0.0.1:1311 will work. You can use the computer name, actual IP address, or other self-identifying information in place of the loopback.

Aside from that I have no further ideas.

Thanks

it actually seems that it have to be some weired combination of Windows/Update, OMSA and the hardware.

This version of OMSA is compatible with server 2016, so I would think the compatibility issue would be between the iDRAC and server 2016. The driver used by the OS to facilitate communication between the OS and iDRAC would be my guess where the problem lies. Compatibility issues can be very difficult to track down if you aren't a software developer though, and I'm not a developer.

Hallo Daniel,

it actually seems that it have to be some weired combination of Windows/Update, OMSA and the hardware.

I tried adding manually a new service with the executable I am starting. But actually the behaviour is the same. It noticed that the status of the service switches to "running" for a little moment, before it is crashing.

I have one last idea: could you please send me a screenshot of your "DSM SA Data Manager" service? Maybe some start parameter has been corrupted due to the Windows update or something else.

If we cannot find here any difference, I probably stick to the found workaround: I keep the user logged in and this user is executing the application, then everything is working fine. Of course a service is more convinient, but I think we have no options left.

Many thanks for your patient help

Here are some screenshots of my service (sorry again in German, as Windows is German).

Thanks for the screenshots. Unfortunately there are no differences. I am not sure, if the driver could be the problem. I would have expected, that when it is related to something so basic like the driver that it would also not work when manually starting the exe. Actually I am a software developer, but of course I have no insights to this OMSA. It seems that something different happens when the application is manually started or as service.

Have tried see in event viewer Windows ? 

Peraphs you have conflict with visual c++ redistribuible installed on your machine

Can't see any further hints in the windows events viewer.

I haven't changed anything and it was one day no longer working. So I would wonder why it has something to do with the c++ redis. How can I verify this? Would you recommend installing it on spec?