none
The ordinal 231 could not be located in the dynamic link library iertutil.dll.

    Question

  • Hi.

    I have been having problems with Internet Explorer on my Vaio Laptop for a while.

    It appears the message:

    The ordinal 231 could not be located in the dynamic link library iertutil.dll.

    Internet Explorer won't run, every programs that relates to IE won't work also and the messages keeps appearing everytime.

    I tried to delete it from the laptop but it wouldn't work.

    How can I solve this? I would appreciate any help.

    Thanks.

    Wednesday, January 25, 2012 3:07 AM

Answers

  • You may try to reregister the iertutil.dll file.


    @ Leo

    Do we know what version of IE is involved?   FWIW  DependencyWalker  on my  IE9  (on W7 X64)  shows that there is no entry point for  DllRegisterServer or DllInstall, so that wouldn't be an option for me.   Recent versions of IE keep changing the ones which can be registered it seems.   Also, in any case I think best results are only obtained by doing this from an elevated cmd window.

    Also, I wonder if "ordinal 231" refers to decimal or hex?  E.g. DW shows decimal 231 is there but 561 (0x0231) is not.   It might help to know which module is trying to do the call.   DependencyWalker could show that too, e.g. using its Profiling trace tool.

    However, recently I discovered that DW has a command line option for showing whether modules that a module calls might need to be registered.   E.g. to do that in PowerShell I would do this:

    invoke-Command {cmd /c depends.exe /of:ieutil.dwf /c %windir%\System32\ieutil.dll}

    (e.g. if your cmd Path shell variable points to a directory which contains depends.exe; otherwise use an explicit filename path.)

    then this (for convenience of analysis--may only help in a X64 context)

    gc iertutil.dwf | select-string -pattern " 6] | DllR| DllIns"

    (There are a few unwanted DllR entry points not filtered out by this loose search.  If it is not done for a 64-bit case I would make it begin with " ]  so the containing filenames show.  I think it is safe to ignore ^]  e.g. Import cases.)

    And then capture that output and do Regular Expression finds for    DllR| DllIns.   Another reason to do this with PowerShell.

    Doing that finds that there are a lot of other modules which might have to be registered if their reporting by DW in this context means something--some that I have never seen anybody suggest be re-registered but that may be an IE9 difference.   I am also seeing even more changes in IE10 coming up using this technique.

    FYI

    Robert
    ---

    Friday, January 27, 2012 5:20 PM
    Answerer

All replies

  • Hi,

      

    Also you can follow this article to fix IE:

    http://support.microsoft.com/kb/318378

     

    Hope that helps.

     

    Regards,

    Leo   Huang

     

     


    Leo Huang

    TechNet Community Support


    Friday, January 27, 2012 8:00 AM
    Moderator
  • You may try to reregister the iertutil.dll file.


    @ Leo

    Do we know what version of IE is involved?   FWIW  DependencyWalker  on my  IE9  (on W7 X64)  shows that there is no entry point for  DllRegisterServer or DllInstall, so that wouldn't be an option for me.   Recent versions of IE keep changing the ones which can be registered it seems.   Also, in any case I think best results are only obtained by doing this from an elevated cmd window.

    Also, I wonder if "ordinal 231" refers to decimal or hex?  E.g. DW shows decimal 231 is there but 561 (0x0231) is not.   It might help to know which module is trying to do the call.   DependencyWalker could show that too, e.g. using its Profiling trace tool.

    However, recently I discovered that DW has a command line option for showing whether modules that a module calls might need to be registered.   E.g. to do that in PowerShell I would do this:

    invoke-Command {cmd /c depends.exe /of:ieutil.dwf /c %windir%\System32\ieutil.dll}

    (e.g. if your cmd Path shell variable points to a directory which contains depends.exe; otherwise use an explicit filename path.)

    then this (for convenience of analysis--may only help in a X64 context)

    gc iertutil.dwf | select-string -pattern " 6] | DllR| DllIns"

    (There are a few unwanted DllR entry points not filtered out by this loose search.  If it is not done for a 64-bit case I would make it begin with " ]  so the containing filenames show.  I think it is safe to ignore ^]  e.g. Import cases.)

    And then capture that output and do Regular Expression finds for    DllR| DllIns.   Another reason to do this with PowerShell.

    Doing that finds that there are a lot of other modules which might have to be registered if their reporting by DW in this context means something--some that I have never seen anybody suggest be re-registered but that may be an IE9 difference.   I am also seeing even more changes in IE10 coming up using this technique.

    FYI

    Robert
    ---

    Friday, January 27, 2012 5:20 PM
    Answerer