How to resolve the "ddedll.dll missing or out of date" error


This article describes resolving an error when using the DDE API component.


After installing the API components on a 64-bit version of Windows it is possible that when enabling DDE clients, or logging into the Trader Workstation (TWS) with the DDE clients enabled, you will get the error message, "The ddedll.dll file required for Excel Integration is missing or out of date." This message occurs because you are running TWS in an instance of the 64-bit version of the Java Virtual Machine, and attempting to load the ddedll.dll library, which is a 32-bit component. To resolve this issue you will need to install the 32-bit version of Java and complete one of the below sets of actions based on how you launch TWS and the version of Java you are using:


Java 8 or Java 7 (update 55 and higher) with the web start version of TWS:
Starting with Java 7 update 55, if you have both the 32-bit and 64-bit versions of Java installed, Java Web Start applications will use the 32-bit version of Java by default. If you are encountering this error when running the web start version of TWS, installing the latest version of the 32-bit Java Runtime Environment should resolve the issue.
Java 8 with the standalone version of TWS:
1) Navigate to C:\Program Files (x86)\Java\ directory and examine the latest version of Java. Take note of the folder name. In the example below, jre1.8.0_25 is the latest version.
2) Search for Trader Workstation 4.0 shortcut icon on your desktop.
3) Right-click on the shortcut icon and select Properties.
4) Under shortcut, click in the Target box and move the blinking cursor to the left until you can read C:\…
5) In the Target box, change the path of javaw.exe to “C:\Programs Files (x86)\Java\<latest Java folder>\bin\javaw.exe” where the <latest Java folder> portion is replaced with the folder name you found in step 1) above. In this example, the path will be “C:\Program Files (x86)\Java\jre1.8.0_25\bin\javaw.exe”. Be sure to include the double quotation marks (“) at the beginning and end of the path.
6) Click Apply and OK button.
7) Login to the TWS.
Note: Windows update KB3039066 for Windows 7 negatively impacted the symlinks converting your localised system paths into absolute ones. This will prevent the modified direct access icon from working. If your operating system is not in English language you will have to make sure the path to your 32-bit Java is in English ("C:\Program Files (x86)") instead of your machine's ("C:/Programme (x86)" assuming your Operating System is in German).
Java 7 with the standalone version of TWS:
1) Search for Trader Workstation 4.0 shortcut on the desktop.

2) Right-click on the shortcut and select Properties.

3) In the Target field of the Shortcut tab, move the blinking cursor to your left until you
read C:\Windows\System32\Javaw.exe…

4) Now, you need to change the word “System32” to “SysWOW64”. Please see image

5) Then, click Apply and OK button.
6) You restart the TWS.

The above directions should resolve this issue, if you have any further problems with the Excel DDE workbook or are still experiencing the same error message then it is possible you may not have the latest version of Java installed.
Please refer to the following IBKR article which will explain you how to install both the 32-bit and 64-bit versions of the latest Java Runtime Environment:
Conflicting programs:
Please be aware that there are some programs that can block the DDE Client connections, for example: Chrome, VLC Player or Adobe Creative Cloud.
In case you are using these programs, please keep them closed while you are using the Excel DDE workbook.


TWS And MultiCharts Advanced Charting FAQ's


Since build 944, the Trader Workstation offers integration with MultiCharts for TWS. This article provides a basic FAQ.

Background: advanced charting is now integrated into TWS as a complement/upgrade to our existing interactive charts. The tool is free of charge to IB customers and includes:

  • Advanced charting
  • Drawing tools and a large library of more than 300 indicators
  • User-programmable technical indicators
  • Strategy backtesting
  • User-programmable trading strategy signals

User-programmable features can be programmed using C# or Visual Basic. If you decide you want to transmit orders from to TWS, you can upgrade to the trading version of for $39.00 per month (following a one-month free trial).

MultiCharts PowerLanguage
We also offer a more advanced flavor of MultiCharts for customers who are not programmers, but who require sophisticated features including automatic order transmission from MultiCharts to TWS and the ability to program complex custom technical indicators. This version, MultiCharts PowerLanguage, offers all of the charting features of along with PowerLanguage, a more user-friendly computer programming language with a small learning curve that was designed to be used by non-programmers. The PowerLanguage version is available for $39.00 per month (following a one-month free trial).

Please note that MultiCharts is currently not supported for accounts holding a large number of positions and these accounts may experience stability issues if they use the tool. Also note that these two products are independent, and charting details set up in will not be transferred over to MultiCharts PowerLanguage.

To download and install MultiCharts, from the New Window drop-down in Mosaic select MultiCharts. From TWS, use the Analytical Tools menu. Choose to download either (free) or MultiCharts PowerLanguage ($39.00/month following free one-month trial). Please note that the initial download may take some time.

Questions and Answers

Q: What is the recommended build of the TWS in order to interface with MultiCharts for TWS and MultiCharts.NET for TWS?

Answer: TWS build 944 or above.

Q: Is the MultiCharts for TWS interface compatible with Mac/Linux machines?

Answer: No. MultiCharts is a Windows-only software. 

Q: Is MultiCharts for TWS compatible with both 32-bit and 64-bit systems?

Answer: Yes. MultiCharts for TWS is compatible with both 32-bit and 64-bit system. 

Q: Does the customer need to install anything prior to the use of MultiCharts for TWS?

Answer: No, the installation of the needed packages takes place automatically when starting the platform from within the TWS.

Q: Is any additional configuration in the TWS needed to be able to use MultiCharts for TWS?

Answer: No additional step on the TWS side is needed - all components of the software that are needed for the launch are included in the TWS. Then, after the launch has started, the software automatically downloads all necessary components.

 Please note, that it is not necessary to enable “ActiveX and Socket client connection” in the API configuration window of the TWS.

Q: Is there any prerequisite to be met prior to the launch, such as a special Java version, etc.?

Answer: No, there isn't, but the user needs to be administrator of the machine, he starts the platform on, or at least an administrator has to perform that during the first launch. This is due to the installation of some system components at the beginning.

Q: Is it possible to connect other third party software to the TWS at the same time?

Answer: Yes. It is possible to connect other third party software at the same time. However, user may have to adjust the connection setup of the third party application. Please note that third party application must provide a unique client id number in order to interface with TWS. MultiCharts for TWS utilizes client id zero (Client id = 0) as the default value. In third party application setup, it is critical that user must verify the client id number and make sure it is not assigned to zero. If it is assigned to zero, then user must adjust the client id number.

 If user can't determine the client id number of this non-MultiCharts third party application, then IB strongly recommend that user must consult with the third party vendor for verification.

Q: What happens if another version of MultiCharts is installed on the user's computer?

Answer: The two versions may exist simultaneously as they are different programs.

Q: How will the update take place?

Answer: This happens automatically - version control is done at the application’s start and the user is presented with the option to update or to do that later.

Q: What is the difference between the two versions of the platform: MultiCharts PowerLanguage for TWS and MultiCharts.NET for TWS?

Answer: With the . NET version at the end of the Trial period of 30 days (no matter if you have traded or not from within this application), you will need to pay if you want to keep your trading privileges, otherwise you can continue using the other features of MultiCharts.NET for TWS.

The Multicharts PowerLanguage for TWS will lose all functionality at the end of the 30 days of the Trial period and you will have to obtain a license in order to continue using the application.

If a user starts with .NET and then decides he wants the PowerLanguage subscription version, whatever configuration has been set up in the .NET version is discarded. The two platforms work like two discrete products.

Compatibility between MetaTrader and IB


IB provides to its account holders a variety of proprietary trading platforms at no cost and therefore does not actively promote or offer the platforms of other vendors. Nonetheless, as IB's principal trading platform, the TraderWorkstation (TWS), operates with an open API, there are numerous third-party vendors who create order entry, charting and various other analytical programs which operate in conjunction with the TWS for purposes of executing orders through IB. As these API specifications are made public, we are not necessarily aware of all vendors who create applications to integrate with the TWS but do operate a program referred to as The Marketplace@IB which operates as a self-service community bringing together third party vendors who have products and services to offer with IB customers seeking to fill a specific need.

While MetaTrader is not a participant in The Marketplace@IB, and does not support integration with the TWS, different vendors such as Trade-Commander (, and jTWSdata ( do offer software which they represent acts as a bridge between MetaTrader and the TWS. As is the case with other third-party software applications, IB is not in a position to provide information or recommendations as to the compatibility or operation of such software.

Ninja Trader Integration with TWS - FAQs


Q: Is Ninja Trader Compatible with the Trader Workstation (TWS)?
A: Yes. The TWS Application Program Interface (API) accommodates connection to a variety of third-party vendors, including Ninja Trader, who offer complementary order entry, charting, back-testing and analytics software programs designed to expand the functionality of TWS. Please refer to the following Ninja Trader website link for details:
Q: Can Ninja Trader be tested with the TWS platform demo which IB makes available to prospective clients via the website?
A: Yes, but only on a limited basis as the platform demo is solely intended to demonstrate the functionality of the TWS and its API. As background, the TWS demo simulates a “live” stream of simulated market data using previous week's ticks and does not offer the historical data necessary to populate Ninja Trader charts requiring a combination of streaming and historical data.  Once your live IB account is approved and funded a paper trading account may be requested, the market data subscriptions to which will accommodate full testing of the Ninja Trader application.
Q: Is Ninja Trader compatible with all versions of TWS?
A: No. There is an inherent lag between the time IB releases a TWS update and that at which any third-party vendor can reasonably respond with a corresponding software upgrade. In the case of Ninja Trader, its application is compatible solely with the standalone TWS platform (not the browser based) and to determine the particular version currently supported, please refer to the following Ninja Trader website link: 
Q: Can the free delayed market data feed from IB be used with Ninja Trader?
A: No. Delayed market data is not relayed through the IB API and account holders seeking to use IB as a data source must subscribe to a real-time data feed through Account Management.
Q: Is there any distinction between the rate at which Ninja Trader seeks to load chart data and that which the IB market data feed supports?
A: As queries which request the same historical data within a short period of time may result in excessive back end server load, IB imposes pacing restrictions which, if violated, will generate error codes. In certain circumstances, the pacing of data requests through IB may delay the loading of the data through Ninja Trader, particularly when multiple charts and or symbols are loaded simultaneously. For details regarding the limitations IB imposes with respect to historical data queries, please refer to the following IB API guide link:
Q: Does IB support the market data required to populate Ninja Trader Range Bar charts?
A: Range Bar charts generally depict the movement of price for a particular instrument over a defined time period (e.g. month, day, 5-minute, 3-minute, etc.) or tick increment. As these types of charts are built from tick data and IB does not support unfiltered tick-by-tick data on a real-time or historical basis, Ninja Trade Bar charts require an alternate data source to eliminate data gaps.
Please refer to the following Ninja Trader website link for a list of supported connectivity providers as well as the historical and real-time data provided by each:
Q: It is possible to use different data source vendor between TWS and Ninja Trader interface?
A: Yes. It should be noted that Ninja Trader does not operate as a vendor of market data and use of this application requires provision of data by a third-party connectivity provider. While IB can serve as this provider for real time prices, these prices are not provided on an unfiltered tick-by-tick basis, a prerequisite for fully populating Ninja Trader charts.  A common setup therefore, is to use Ninja Trader as a front-end order entry platform, routing orders to the TWS for execution and clearing by IB and bridge to a third-party vendor for market data.
Q: Is Ninja Trader compatible with IB’s paper trading (simulation) account?
A: Yes Ninja Trader connects to the paper trading account in the same manner as to the live account. To familiarize oneself with the configuration and operation of these applications, IB strongly recommends conducting test trades through the paper trading account prior to submitting orders through the live account.
Q: How can orders submitted through Ninja Trader for execution through TWS monitored with TWS?
A: The TWS contains a page denoted by a tab marked “API” within the main window through which open orders submitted via Ninja Trader or any third party software application may be monitored. 
Q:  Is Ninja Trader compatible with IB’s Financial Advisor and Friends & Family account type?
A:  Yes, although not with the full order allocation functionality provided directly through the TWS. While Ninja Trader can be used to submit orders for a client sub-account through the Advisor master account, it does not allow for a single order to be allocated to more than one sub-account. This is in contrast to the TWS user interface which provides for multi-client trade allocations from a single order (through the Account Group or Allocation Profile options).
Q: How does one determine the cause of orders which have been submitted via Ninja Trader and subsequently canceled or rejected?
A: An order which has been canceled or rejected will be accompanied by an error message generated by Ninja Trader and/or TWS depending upon the source of the action. Order cancellations/rejections may be attributable to a variety of factors including IB credit policies, exchange restrictions or an invalid user request. In situations where the error message is not self explanatory, the user will need to contact the technical support teams of IB and Ninja Trader to diagnose and troubleshoot the problem.


Considerations for Optimizing Order Efficiency

Account holders are encouraged to routinely monitor their order submissions with the objective of optimizing efficiency and minimizing 'wasted' or non-executed orders.  As inefficient orders have the potential to consume a disproportionate amount of system resources. IB measures the effectiveness of client orders through the Order Efficiency Ratio (OER).  This ratio compares aggregate daily order activity relative to that portion of activity which results in an execution and is determined as follows:


OER = (Order Submissions + Order Revisions + Order Cancellations) / (Executed Orders + 1)

Outlined below is a list of considerations which can assist with optimizing (reducing) one's OER:


1. Cancellation of Day Orders - strategies which use 'Day' as the Time in Force setting and are restricted to Regular Trading Hours should not initiate order cancellations after 16:00 ET, but rather rely upon IB processes which automatically act to cancel such orders. While the client initiated cancellation request which serve to increase the OER, IB's cancellation will not.

2. Modification vs. Cancellation - logic which acts to cancel and subsequently replace orders should be substituted with logic which simply modifies the existing orders. This will serve to reduce the process from two order actions to a single order action, thereby improving the OER.

3. Conditional Orders - when utilizing strategies which involve the pricing of one product relative to another, consideration should be given to minimizing unnecessary price and quantity order modifications. As an example, an order modification based upon a price change should only be triggered if the prior price is no longer competitive and the new suggested price is competitive.

4. Meaningful Revisions – logic which serves to modify existing orders without substantially increasing the likelihood of the modified order interacting with the NBBO should be avoided. An example of this would be the modification of a buy order from $30.50 to $30.55 on a stock having a bid-ask of $31.25 - $31.26.

5. RTH Orders – logic which modifies orders set to execute solely during Regular Trading Hours based upon price changes taking place outside those hours should be optimized to only make such modifications during or just prior to the time at which the orders are activated.

6. Order Stacking - Any strategy that incorporates and transmits the stacking of orders on the same side of a particular underlying should minimize transmitting those that are not immediately marketable until the orders which have a greater likelihood of interacting with the NBBO have executed.

7. Use of IB Order Types - as the revision logic embedded within IB-supported order types is not considered an order action for the purposes of the OER, consideration should be given to using IB order types, whenever practical, as opposed to replicating such logic within the client order management logic. Logic which is commonly initiated by clients and whose behavior can be readily replicated by IB order types include: the dynamic management of orders expressed in terms of an options implied volatility (Volatility Orders), orders to set a stop price at a fixed amount relative to the market price (Trailing Stop Orders), and orders designed to automatically maintain a limit price relative to the NBBO (Pegged-to-Market Orders).

The above is not intended to be an exhaustive list of steps for optimizing one's orders but rather those which address the most frequently observed inefficiencies in client order management logic, are relatively simple to implement and which provide the opportunity for substantive and enduring improvements. For further information or questions, please contact the Customer Service Technical Assistance Center.


Order Management Overview


IB’s order management and routing systems are negatively impacted when the volume of orders submitted by clients is significant relative to those which are actually executed. Left unchecked, unproductive orders have the potential to slow system performance, adversely impact other clients and increase capacity requirements and costs. To minimize the load of such orders on internal systems and to comply with exchange policies, certain of which impose a surcharge for excessive messages, IB monitors order activity and may place restrictions upon clients who routinely submit a disproportionate number of unproductive orders.
The Order Efficiency Ratio (OER) allows IB to evaluate order productivity by comparing aggregate daily order activity relative to that portion of activity which results in an execution. This ratio is as follows:
OER   =   (Order Submissions + Order Revisions + Order Cancellations) / (Executed Orders + 1)
An OER above 20 is generally considered excessive and indicative of inefficient order management logic. Clients who routinely report an OER above 20 will receive notification of their ratio and are advised to review and optimize their logic and those who fail to take action or who report a particularly egregious ratio may be subject to trade restrictions or bandwidth usage fees.1
Clients submitting orders through an API can often realize significant declines in their OER through slight modifications to their order logic.  Please review KB1765 for a list of the most common techniques for optimizing this ratio.  
1 It should be noted that these actions are not aimed at the client who submits 200 orders and receives 10 executions but rather those using automated systems to submit thousands of orders with negligible interaction with the NBBO.


Security considerations following SLS opt out

Account holders who have elected to opt out of IB's Secure Login System (SLS), and effectively relinquish the protections afforded by two factor authentication, are strongly encouraged to familiarize themselves with and utilize alternative best practice security measures, a number of which are discussed below. 

It's important to note that while none of these measures, on either an individual or collective basis, is deemed equivalent to the SLS in terms of protection and, in fact, are recommended as complementary measures, opting out of SLS serves to increase their relevance.


IP Restrictions:

One way to add protection or a level of security to your IB Trading account while not utilizing a Secure Login Device would be to setup IP restrictions.  By selecting this setting through Account Management you're telling Interactive Brokers that you only want access to your trading account(s) from a specified IP address, or a range of IP addresses. In addition, should you have multiple authorized traders for a given account, these restrictions can be set at the individual trader level. 

To implement IP restrictions you will need to log into Account Management using your security device and mouse-over the Manage Account menu then click on Security and then on IP Restrictions. This will take you to the "Manage IP Address Restrictions" screen. From there click on the Add IP Address Restriction button, select the trader user name from the drop-down list, enter the IP address from which you connect (xx.xx.xx.xx.xx.xx) and click on the Submit button. Note that any updates do not take effect immediately but rather the following business day.

To find the IP address of your PC please follow the below steps.  (Please note that the below will only give you the local PC address. If you are using any type of router in your home network please make sure you use your WAN IP address.   Any IP address that starts with 192.XXX.XXX.XXX is most likely your LAN IP, and not your WAN IP.  You can find your WAN IP by calling your ISP and asking them for it.)

  • Click on the Start button in the lower left hand corner f your screen;
  • Click on Run;
  • Type “cmd” in the Run box and then click enter on your keyboard.  An MS DOS Window will   open
  • Type “ipconfig” into the MS DOS Window and then click enter on your keyboard.  Your IP address will be displayed.

Important Notes:

The IP restriction feature is only intended where the IP address is static, or remains constant.  In certain instances your computer’s IP address may be assigned automatically and in a dynamic or changing manner by your network administrator or Internet Service Provider.  IB recommends that you confirm that your address is static prior to using this restriction feature.

While the use of the IP restriction feature will restrict access to the IP address(es) you specify, you must be aware it isn't 100% full proof against very advanced electronic thieves who know how to spoof, and or mask an IP Address. it should be noted that this feature alone will not necessarily prevent unauthorized access by any hacker having your user name and password along with the ability to ‘spoof’ your IP address.

Securing Your Network

  • Use a firewall making sure ports 4000 and 4001 are open for TWS access.
  • Never use a wireless session (WI-FI) which is unsecured or not operated by you. If the use of a unsecured network (e.g. public Wi-Fi hotspot) becomes necessary, do not log into any financial institution account you may have including your IB account.
  • When logging into the TWS, check the “Use SSL” box on the login screen.  By using SSL, or Secure Socket Layer, all information passed to and from your computer is protected using 128-bit encryption.  Note, however, that checking this box may cause you to experience minor performance impacts depending on the capabilities of your PC.
  • Use antivirus software to identify and eliminate viruses you may have downloaded to your computer accidentally.  As new viruses are constantly being created, you need to update your antivirus software regularly.
  • Use anti-spyware software to detect and remove spyware programs which can collect various types of personal information, monitor your browsing activity and interfere with the control of your computer.


If you have any other questions please feel free to contact IB's Technical Support center. 



Beginning in 2006, working groups comprised of brokers, exchanges, clearing houses and vendors were formed in order to represent each of the U.S. and Canadian securities industries in a multi-year effort to develop a revised data format for representing listed option symbols. These efforts, referred to as the Option Symbology Initiatives (OSIs), are intended to provide the following benefits:
-         Decrease the number of errors in the front, middle and back office processes.
-         Represent the vast majority of listed option contracts using the same symbol as the
           underlying security to reduce investor confusion.
-         Reduce corporate action symbol conversions.
-         Eliminate wrap symbols.
-         Eliminate the need for LEAP rollover process.
-         Reduce the frequency of coordination among exchanges for symbol elections.
-         Support the growth in product listings through additional expiration events and more
           flexible strike price designations.
The following article provides background information regarding the products impacted by the OSI, the revised data format, project timeline and client impact as well as external links where additional information may be found.
The table below lists the product classifications of the US and Canadian exchange listed options which are impacted by the OSIs.  Note that while the mandated conversion date for Canadian options is identical to that of the US (i.e., February 12, 2010), the conversion of Canadian options was accelerated and completed by IB in September 2009.
Equity (short cycle, regular full cycle and long term)
Yield Based
Foreign Currency
Short Dated
Each OSI will replace the 5-character code with a 21-character OSI identifier to be used in the transmission of listed option contracts between exchanges, the clearinghouses and their constituents. The 21-character OSI identifier comprises six data elements arranged in logical order, each with a minimum field size. An example is provided in the table below.  


5-character Code
21-character OSI Identifier*
OSI Data Elements (minimum field size)
Option Root
SPX    111216P01900000
MSFT  100116C00047500
*If the Option Root Symbol is less than 6 characters, spaces are added to equal the six character minimum.
The industry effort has been organized into two phases:
1. The Conversion Phase in which the OPRA code format will be dropped and the 21-character record layout employed to include the expiration day and decimal strike price. This phase was completed on February 12, 2010; and
2. The Consolidation Phase during which LEAPS, wrap, FLEX, short-dated and non-standard delivery contracts will have their symbols consolidated to that of the underlying (e.g. MSQ to MSFT).  This phase will take place over the 5 weekends starting March 12, 2010 and ending May 14, 2010. Note that there are certain contracts, referred to by OCC Class Consolidation Exceptions, which will not be consolidated.  These contracts include binary and CDO options, options having a 5 character underlying as well as  options having unique settlement terms (e.g., settle on open).  In addition, adjusted symbols which are the result of a prior corporate action will be consolidated to the new OSI corporate action format at the time the underlying class consolidates.
Outlined in the table below are the key milestone and effective dates for this consolidation phase and the products impacted.
Milestone Date Action Issues/Series Impacted Effective Date
Friday, March 12, 2010 Initial group of options representing array of product scenarios to be consolidated (approx 12 classes) Options associated with a strategic group of underlyings including adjusted and non-standard symbols Monday, March 15, 2010
Saturday, March 20, 2010 Standard Expiration    
Wednesday, March 31, 2010 Quarterly Expiration    
Friday, April 9, 2010 Consolidation of options whose primary underlying starts with the letters A-C (approx 503 classes) All options associated with 'A-C' underlyings including adjusted and non-standard symbols Monday, April 12, 2010
Saturday, April 17, 2010 Standard Expiration    
Friday, April 23, 2010 Consolidation of options whose primary underlying starts with the letters D-I (approx 486 classes) All options associated with 'D-I' underlyings including adjusted and non-standard symbols Monday, April 26, 2010
Friday, May 7, 2010 Consolidation of options whose primary underlying starts with the letters J-IR(approx 575 classes) All options associated with 'J-R' underlyings including adjusted and non-standard symbols Monday, May 10, 2010
Friday, May 14, 2010 Consolidation of options whose primary underlying starts with the letters S-Z (approx 503 classes) All options associated with 'S-Z' underlyings including adjusted and non-standard symbols Monday, May 17, 2010
During this consolidation phase Good-till-Canceled (GTC) and Good-till-Date (GTD) orders will need to be canceled for all the option classes which are scheduled to consolidate. To accommodate this exchange mandate, IB will cancel all customer GTC and GTD orders on the Sunday of each milestone cycle.  Confirmation of these cancellations (outs) will be provided prior to effective date open (Monday) at which point customers may re-enter these orders utilizing the post consolidation symbol.
For additional information, please visit the symbology initiative sections of the OCC and Montreal Exchange websites.  


Syndicate content