If you run a FlexNet Operations Portal and it uses an Oracle database on the same Windows server, you may find that it fails to startup correctly when your host restarts.
The problem I found was that insufficient dependencies are set up between the two Windows services, and they get into a race at startup. The FlexNet service always seems to get there before Oracle, gets locked up and never recovers.
My fix was to add a dependency between the two services, using:
sc config FlexNetOperations depend= Tcpip/Afd/MyOracleInstanceService
This makes the FNO wait until the Oracle service is started, which has fixed the problem for me at least.
Note, you need to reapply this fix every time you re-deploy the FNO software.
Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts
Tuesday, November 28, 2017
Friday, July 19, 2013
unexpected precompiled header, simply rerunning the compiler might fix this problem
This post is about Microsoft's answer to the IT Crowd and their "did you try turning it off and on" running gag.
For years, we (at work) have been plagued with this particular error that seemed to happen spontaneously, hang around for a while then disappear, and today (with the help of Google) I've been able to track down an actual answer.
Microsoft explains the embarrassing truth here.
In a nutshell, precompiled headers are implemented cheaply as a straight memory dump complete with physical memory addresses. When the compiler subsequently tries to read them back, ASLR has potentially scrambled it's little brain.
There are lots of fixes mentioned around the net, of varying levels of quality and security. Microsoft has a hotfix but it only solves the problem for Visual Studio installs - we build using the Platform SDK.
For me, the sanest approach was:
Note, this has no impact on the output of the compiler - your programs will still be ASLR-enabled or not, depending on what switches you pass on the command line. All we are doing here is fixing the actual compiler itself...
I hoped I'd never have to revisit this post, but today I had to. Looks like EMET can cause quite a bit of damage when you run it.
I tried using EMET 5.2 and it did resolve my problems with the C compiler. As collateral damage, however, it took out Microsoft Office, AutoCAD 2011-2016, and even Internet Explorer. Every one of them reported a vanilla error message "Attempt to access invalid address".
This looked to me to be related to either Data Execution Protection or perhaps to ASLR. However, even though I completely disabled both of those features (through EMET), it didnt' help. I've restarted so many times today you would not believe it. Uninstalling EMET changed nothing. I sat and manually uninstalled every Windows Update that had been applied in the last 48 hours and still no joy.
Eventually this post on the Microsoft Forums pointed me at an obscure registry entry and lo, it fixed the problem. It would appear that EMET automatically puts in registry entries when it is installed, and does not remove them when it is uninstalled (no surprise there).
So, the fix was to go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
and locate the application I was trying to use. I removed the troublesome keys and voila, my apps work again. (Actually, for many, I just removed the value for MitigationOptions which was 0x0000100)
Note: this is not something that you should attempt lightly. No warranty implied or assumed.
Take Three.
It looks like the damage that EMET does is like herpes. Every time I update Microsoft Office (ie, apply office updates), I need to go back in and patch up the registry settings again. No idea why. This must be that "my PC is so broken it needs to be reformatted and start again" that everyone talked about in the 80s.
For years, we (at work) have been plagued with this particular error that seemed to happen spontaneously, hang around for a while then disappear, and today (with the help of Google) I've been able to track down an actual answer.
Microsoft explains the embarrassing truth here.
In a nutshell, precompiled headers are implemented cheaply as a straight memory dump complete with physical memory addresses. When the compiler subsequently tries to read them back, ASLR has potentially scrambled it's little brain.
There are lots of fixes mentioned around the net, of varying levels of quality and security. Microsoft has a hotfix but it only solves the problem for Visual Studio installs - we build using the Platform SDK.
For me, the sanest approach was:
- download and install EMET from here
- use EMET to disable "MandatoryASLR" and "BottomUpASLR" on the C compiler (cl.exe)
Note, this has no impact on the output of the compiler - your programs will still be ASLR-enabled or not, depending on what switches you pass on the command line. All we are doing here is fixing the actual compiler itself...
I hoped I'd never have to revisit this post, but today I had to. Looks like EMET can cause quite a bit of damage when you run it.
I tried using EMET 5.2 and it did resolve my problems with the C compiler. As collateral damage, however, it took out Microsoft Office, AutoCAD 2011-2016, and even Internet Explorer. Every one of them reported a vanilla error message "Attempt to access invalid address".
This looked to me to be related to either Data Execution Protection or perhaps to ASLR. However, even though I completely disabled both of those features (through EMET), it didnt' help. I've restarted so many times today you would not believe it. Uninstalling EMET changed nothing. I sat and manually uninstalled every Windows Update that had been applied in the last 48 hours and still no joy.
Eventually this post on the Microsoft Forums pointed me at an obscure registry entry and lo, it fixed the problem. It would appear that EMET automatically puts in registry entries when it is installed, and does not remove them when it is uninstalled (no surprise there).
So, the fix was to go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
and locate the application I was trying to use. I removed the troublesome keys and voila, my apps work again. (Actually, for many, I just removed the value for MitigationOptions which was 0x0000100)
Note: this is not something that you should attempt lightly. No warranty implied or assumed.
Take Three.
It looks like the damage that EMET does is like herpes. Every time I update Microsoft Office (ie, apply office updates), I need to go back in and patch up the registry settings again. No idea why. This must be that "my PC is so broken it needs to be reformatted and start again" that everyone talked about in the 80s.
Tuesday, March 31, 2009
Building MFC applications with Visual Studio .NET 2008 Express
For reasons best known to themselves, Microsoft really really don't want you to build traditional MFC-based applications with their new Developer Studio tools - if you want the free stuff, you gotta trade in those testicles and do things with .NET or .nothing. None of the MFC libraries come in the latest Express (read: free) versions of Developer Studio, nor do such useful tools as RC and MIDL.
though in true Microsoft style, those headers contain compile errors.
Line 1034 and 1036 of …\include\mfc42\afxwin1.inl will probably contain the following:
_AFXWIN_INLINE CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }
which is incorrect – they generate error 4430. It should be:
_AFXWIN_INLINE BOOL CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE BOOL CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }
(And people blame Windows crashes on "bad drivers" - how hard can it be to write a driver when the DDK has such blatant errors - they literally cannot have tried to compile with these headers before shipping them)
However...
You can get RC and MIDL from the Platform SDK.
And you can get an old version of the MFC and ATL libraries from the Driver Development Kit.
Line 1034 and 1036 of …\include\mfc42\afxwin1.inl will probably contain the following:
_AFXWIN_INLINE CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }
which is incorrect – they generate error 4430. It should be:
_AFXWIN_INLINE BOOL CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE BOOL CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }
(And people blame Windows crashes on "bad drivers" - how hard can it be to write a driver when the DDK has such blatant errors - they literally cannot have tried to compile with these headers before shipping them)
Sadly, whats discussed here only works up to VC8.0 - at 9.0 the ATL changes are too drastic, as I found out the hard way. If you want to use MFC or ATL, you can't use Visual Studio 2008 Express.
Subscribe to:
Posts (Atom)